Standards & technologies of telecom networks management (rus)

А.Ю.

Гребешков

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

2003 г.

В книге рассматриваются вопросы управления современными
сетями связи. В качестве базовой методологии управления
рассматривается сеть управления электросвязью TMN
(Тelecommunication Management Network) на основе рекомендаций
МСЭ-Т серии М.3000. Положения TMN дополняются современными
подходами к управлению на уровне бизнес-процессов операторов,
которые предлагает Форум сетевого управления (TeleManagement
Forum, TMF). В книге приводится базовая информация по структуре
и особенностям протоколов CMIP и SNMP, обсуждаются
особенности управления открытыми системами в рамках
стандартов ISO.
Применительно к задачам управления сетями рассматривается
применение новых информационных технологий и системных
архитектур, таких как ODP, ODMA, CORBA, DCOM (COM+),
OSCA/INA. В книге содержится материал по разработке систем
TMN с использованием средств GDMO и ASN.1 Описываются
общие подходы к реализации систем OSS оператора связи.
Приведён обзор платформ и продуктов сетевого управления
производства компаний Hewlett-Packard, Sun Microsystems, Siemens,
IBM, Телесофт-Россия и других.
Издание рассчитано на специалистов по информационным
технологиям и управлению сетями, разработчиков программного
обеспечения, студентов и аспирантов высших учебных заведений.

Рукопись была издана в 2003 г.
УДК 621.394:615.14
ББК 32.88
А.Ю. Гребешков Стандарты и технологии управления сетями
связи.–М.: Эко-Трендз, 2003. – 288 с.: илл.
ISBN 5–88405–047–X

Стандарты и технологии управления сетями связи

1

Предисловие
Обеспечение качественной работы всех видов услуг связи для пользователей неразрывно связано с вопросами комплексного управления сетями связи. Задача управления
сетью состоит в том, чтобы предоставить оператору возможность нормативной эксплуатации и технического обслуживания сети с минимальными затратами, обеспечивая при
этом требуемый уровень услуг. Наиболее эффективно эту задачу можно решить, основываясь на концепции сети управления электросвязью (Тelecommunication Мanagement Network, TMN).
Интеграция сетей передачи данных и речи, а также поддержка средств мультимедиа на коммуникационных узлах ставит новые задачи перед поставщиками сетевых услуг.
Возросший объем сетевой нагрузки, сложные архитектуры и топологии сетей требуют инструментария, позволяющего контролировать работу любых сетевых средств и систем.
Рассмотрение вопросов, связанных с программными и информационными технологиями,
которые используются для управления современными телекоммуникациями, является
предметом данной книги.
Автор не ставил перед собой цель написать энциклопедию сетевого управления.
Основное внимание уделено вопросам, связанным с различными аспектами управления
глобальными телекоммуникационными сетями, − от организации менеджмента и бизнес−процессов до протоколов управления и применяемых платформ сетевого управления.
В качестве основных протоколов рассматривались CMIP и SNMP. Автор готов согласиться, что надо было больше внимания уделить особенностям управления отдельными видами сетей, в частности IP-сетями, подробнее рассмотреть решения для управления сетями
подвижной связи и мультисервисными сетями. Основной задачей было стремление предоставить читателю базовую сумму знаний по информационным технологиям и системам
управления, которые позволят самостоятельно разобраться в действующих стандартах сетевого управления, осознанно подходить к анализу, выбору и применению решений, которые предлагаются многочисленными фирмами на рынке средств сетевого управления.
В этой связи хочется процитировать слова из выступления министра РФ по связи и
информатизации РФ Л.Д. Реймана на научно-технической конференции МТУСИ 29.01.02:
«Бурное развитие телекоммуникаций постоянно повышает требования к уровню подготовки кадров отрасли. Если раньше требовались грамотные специалисты в области эксплуатации, то сегодня, в условиях интенсивной модернизации отрасли, наряду с квалифицированными эксплуатационщиками требуются специалисты с высоким уровнем общесистемной подготовки и знаниями в области информационных технологий. Сегодня
ощущается острая потребность в специалистах, которые наряду с технологиями хорошо
понимают вопросы маркетинга и корпоративного управления компаниями связи, с развитым системным мышлением, способные решать задачи масштабной модернизации, системного проектирования сетей, эффективного внедрения новейших услуг» (цит. по тексту
«Новости» за 29.01.02 на сайте www.mynsvyaz.ru). Поэтому некоторая часть книги посвящена рассмотрению вопросов общесистемного управления предприятиями связи. В
книге приведён относительно новый для России материал по схемам бизнес-процессов
оператора связи, детально рассмотрено применение некоторых перспективных информационных технологий для управления производством и бизнесом оператора.
С учётом многоплановости материала автор рекомендует следующую последовательность изучения книги для различных групп специалистов :
• для специалистов, желающих получить общее представление о принципах и решениях
TMN, - раздел 1.1, раздел 1.2, глава 3, разделы 6.1, 6.2, 6.3, 6.4, глава 9;
• для тех, кто желает самостоятельно разобраться в основных стандартах управления, –
глава 1, глава 3, глава 4, глава 5, раздел 6.5, раздел 6.6, раздел 7.5, глава 9;
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

2

для специалистов по управлению бизнесом и информационным системам, разработчиков – раздел 1.1, раздел 1.4, раздел 1.5, глава 2, глава 4, глава 6, глава 8, глава 9;
• для тех, кого интересуют основные протоколы сетевого управления, – глава 2, глава 5,
глава 8.
Разумеется, читатель сам вправе определять последовательность ознакомления с
предоставленным материалом.
Предваряя содержательную часть работы, автор хотел бы кратко охарактеризовать
используемые источники информации. Разумеется, не все использованные материалы носят бесспорный характер; на содержание некоторых источников существенное влияние
оказывают результаты конкретных проектов и разработок. Поэтому, чтобы избежать
влияния тех или иных «групп интересов», использованные источники информации были
условно поделены на три группы.
К первой группе относятся руководящие материалы Минсвязи России, рекомендации МСЭ−Т, ETSI и форума TMF. Эти источники, по мнению автора, являются наиболее
надёжными, так как прошли всестороннее критическое обсуждение при наличии обязательного исследовательского периода на подготовку и публичное обсуждение. В процессе
подготовки документов первой группы были заняты многочисленные группы, правительственные и неправительственные организации, частные фирмы и международные корпорации, что не могло не привести к определённому согласию.
Ко второй группе источников относятся материалы диссертационных работ, статьи
в авторитетных российских и зарубежных журналах, материалы фирм−разработчиков, а
также богатый фактический материал, полученный в результате исследований таких институтов как EURESCOM и TMF. Эти источники по степени доверия и добротности материала в большинстве своём не уступают первой группе, но, как правило, не имеют чёткого
официального статуса.
К третьей группе относятся статьи, презентации, выступления по отдельным вопросам. Как правило, третья группа источников использовалась в качестве иллюстративного материала по тем или иным проблемам сетевого управления. Соответственно, в первую очередь, автор использовал первую группу источников, потом − вторую, и в заключении − третью группу.
Иностранные термины и определения даны по тексту с русским переводом и указанием оригинального написания на английском языке. В качестве источника базовых
терминов автор использовал материалы Приложения 2 к Руководящему документу «Основные направления развития ВСС РФ на период до 2005 г.», глоссарий Руководящего
документа «Построение систем управления сетями связи операторов ВСС РФ» (РД 45.174
- 2001). Ряд использованных терминов не значится в ГОСТ, официальных документах
Минсвязи или Ассоциации документальной электросвязи. Поэтому читатель, как и автор,
вправе иметь собственную точку зрения на качество и адекватность перевода.
В заключение хочется процитировать слова русского историка и этнографа: «И даже если найдётся привередливый читатель, который будет недоволен тем, что ему встретятся в тексте места знакомые, упоминавшиеся в других, куда более монументальных работах, то пусть он рассматривает их как информационный архив, заменяющий множество
отсылочных сносок и громоздкую библиографию» (Цитируется по : Древняя Русь и Великая степь / Л.Н. Гумилёв. − M.: ООО «Издательство АСТ», 2002. − С.25).

Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

3

1. ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ СЕТЯМИ СВЯЗИ

1.1

Характеристика объекта изучения

В настоящее время мировая телекоммуникационная индустрия претерпевает революционные изменения. Постоянное развитие телекоммуникационных технологий, появление новых средств и оборудования связи ставит перед операторами сетей и провайдерами телекоммуникационных услуг новые задачи в части поддержания нормативного качества оказания услуг связи. Растущая конкуренция в сфере телекоммуникаций, дерегуляция и демонополизация рынков услуг побуждают как признанных, так и новых операторов искать пути более быстрого внедрения новых услуг и снижения их себестоимости.
Индустрия информационных технологий, способная помочь в решении этих задач, также
находится в стадии бурного развития, что оказывает существенное влияние на развитие
сетей и служб электросвязи.
За последние годы структура телекоммуникационных сетей стала более сложной и
многоплановой. Применение волоконно-оптических линий связи позволило повсеместно
начать применение на первичных сетях технологий SDH, а в последние годы и DWDM.
Наряду с традиционными аналогово-цифровыми телефонными сетями связи бурно развиваются новые цифровые сети связи с коммутацией пакетов, с использованием технологий
Frame Relay, АТМ, MPLS. Повсеместное применение протокола IP и развитие сети Интернет привело к появлению на рынке услуг IP-телефонии. Развитие транспортных сетей
со скоростью передачи данных от 2 Мбит/сек до 64 Гбит/сек и выше повлекло за собой
развитие сетей высокоскоростного абонентского доступа как на базе традиционной технологии ISDN, так и с использованием технологий семейства DSL (ADSL, XDSL, SDSL,
HDSL). В подвижной радиосвязи начинается переход к сетям связи 3-го поколения на базе
стандартов UMTS, CDMA. Сети связи становятся гетерогенными, т.е. состоящими из многих типов оборудования и систем связи. Неизбежно возникает необходимость организации контроля, мониторинга и управления разнородным оборудованием и системами на
основе единых принципов для поддержания нормативного качества обслуживания и требуемого уровня сервиса для различных категорий пользователей.
Конкуренция и существенное расширение номенклатуры услуг связи на рынке
привело к тому, что пользователя привлекает не столько наличие технической возможности организации связи, сколько качественные и количественные показатели, такие как гарантированное качество услуги «из конца – в конец», доступность услуги, наличие постоянной связи, мобильность, универсальность оборудования доступа, гарантия совместимости различных стандартов, возможность поддержки индивидуальных настроек и профиля
клиента, развитая и удобная платёжная система. Поэтому эффективные решения в области
управления телекоммуникациями являются ключевыми компонентами сетей связи любого
масштаба - от локальных сетей масштаба предприятия до национальных и международных (глобальных) сетей. Следует иметь в виду, что конкретные программно-аппаратные
решения по управлению сетями и услугами связи могут быть как интегрированными
(включающими в себя несколько задач управления), так и однокомпонентными, когда
программное средство решает только одну задачу управления.
Оператор сети, нацеленный на лидерство в конкурентной борьбе, должен иметь
центр управления сетями и/или услугами связи, который позволяет ему реализовать следующие функции :
• быстрого внедрения новых услуг для приобретения новых клиентов и получения дополнительных источников доходов;
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

4

поддержки нормативного качества обслуживания клиентов, включая минимизацию
времени восстановления оборудования после сбоев и техническую поддержку пользователей;
• сохранения низких затрат на эксплуатацию сети при разумном соотношении стоимость/производительность сети.
Организация интегрированного управления современными сетями связи требует
применения соответствующих программно-аппратных платформ, которые обеспечивают
необходимый уровень качества предоставляемой услуги связи в любое время и с минимальными эксплуатационными затратами.
Для решения поставленной задачи Международный союз электросвязи (МСЭ)
предлагает использовать концепцию TMN. TMN есть «… специальная сеть, обеспечивающая управление сетями электросвязи и их услугами путём организации взаимосвязи с
компонентами различных сетей электросвязи на основе единых интерфейсов и протоколов, стандартизованных МСЭ-Т» [7].
В концепции TMN реализован комплексный подход к управлению сетями связи,
начиная с управления бизнесом и услугами связи (верхний уровень управления) и заканчивая управлением отдельным устройством или элементом оборудования связи (нижний
уровень управления).
В настоящее время большая часть зарубежных сетей связи имеет достаточно полно
реализованные нижние уровни TMN. В последнее время в связи с конвергенцией услуг и
сетей связи на первое место выступают задачи более высоких уровней. Их успешное решение возможно только при использовании на сетях операторов связи комплекса специализированного программного обеспечения, включающего прикладные системы управления услугами и бизнес-процессами.
Основной идеей TMN является применение специальной архитектуры и технических решений для достижения управляемости различных типов телекоммуникационного
оборудования и систем связи. «Прозрачный» информационный обмен между системой
управления и управляемыми системами позволяет контролировать качественные показатели услуг связи, рабочие характеристики оборудования и систем связи. Для этого используются функциональные элементы TMN со стандартизованными интерфейсами,
включая протоколы управления. Под функциональным элементом здесь понимается компонент TMN, который выполняет определённую функцию, например, функцию коммутационного оборудования, функцию средства передачи данных, функцию отображения информации управления для администрации связи. Разумеется, в рамках концепции TMN
предусматривается и техническая возможность целенаправленного воздействия и изменения характеристик систем и оборудования, например, установка порога перегрузок, изменение характеристик абонента, блокировка направления связи и т.п.
Согласно рекомендациям МСЭ-Т серии M.3xxx, TMN представляет собой отдельную сеть, которая имеет интерфейсы с телекоммуникационной сетью в обусловленных
точках стыка. Эти интерфейсы используются для обмена информацией управления и
приёма-передачи управляющих команд между системой управления и сетью связи.
В сферу управления TMN попадают практически все существующие в настоящее
время виды сетей и систем связи, а также типы телекоммуникационного оборудования:
• сети связи общего пользования различного назначения и частные/выделенные сети;
• сама TMN (т.е. управление TMN);
• оборудование систем передачи (мультиплексоры, кросс-коннекторы, каналообразующее оборудование и т.д.);
• линии связи (медные и волоконно-оптические кабельные системы, радиорелейное
оборудование, спутниковые системы связи);
• операционные системы программно-управляемого оборудования связи;
• аппаратное обеспечение вычислительных комплексов;
• цифровые и аналоговые коммутаторы;
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

5

сети передачи данных, включая информационно-вычислительные сети (локальные и
глобальные);
• сети связи с коммутацией пакетов;
• системы сигнализации;
• услуги широкополосной передачи и телесервисы;
• УАТС;
• пользовательские терминалы ЦСИО;
• программное обеспечение, необходимое для предоставления телекоммуникационных
услуг (например, интеллектуальные услуги, IP-сервисы);
• прикладное программное обеспечение (ПО) вычислительных систем (включая ПО
TMN);
• системы электропитания, инженерного обеспечения (тестовые модули, системы питания, системы кондиционирования воздуха, системы охранной сигнализации и т.д.).
Итак, концепция TMN предполагает прежде всего организацию управления разнородным телекоммуникационным оборудованием по единым принципам с использованием
современных информационных технологий.
С точки зрения архитектуры системы сетевого управления возможны варианты,
представленные на рис.1.1.

Централизованная

Одноуровневая

Иерархическая

Условные обозначения :
Центр управления
Управляемые объекты

Рис.1.1 Варианты архитектуры сетевого управления
Самый общий анализ архитектур на рис.1.1 показывает, что централизованная схема является самой простой и предназначена для управления сетями связи на географически ограниченной территории, например, в пределах одного города или, в крайнем случае,
региона. Одноуровневая архитектура может использоваться при взаимодействии нескольких управляющих систем (центров сетевого управления), а иерархическая архитектура для управления крупными, территориально−распределёнными, в том числе национальными сетями связи.
Решение задач управления является одной из важнейших в «Концепции развития
Взаимоувязанной сети связи Российской Федерации» [1,4]. В частности, при определении
понятия ВСС указано, что «Взаимоувязанная сеть связи Российской Федерации - это
комплекс технологически сопряжённых сетей электросвязи на территории Российской
Федерации, обеспеченный общим централизованным управлением» [6].
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

6

Внедрение централизованного сетевого управления в России, как и во всём мире,
сегодня затрудняется в связи с разнородностью телекоммуникационных технологий и типов оборудования, применяемых на сетях связи, включая и сами системы сетевого управления. Это приводит к появлению ряда проблем, таких как дублирование информации,
возникновение противоречивых данных, дополнительные временные затраты на синхронизацию информации в различных системах [12]. Неоднородность систем управления
может вызвать прерывания в информационных потоках, замедление процессов выработки
управляющих команд и повышение вероятности возникновения ошибок.
Сложность внедрения единого сетевого управления в рамках региональных и местных сетей связи (которые надо рассматривать как базовые в процессе предоставления услуг связи большинству населения России) определяется следующими факторами:
• большое разнообразие типов телекоммуникационного оборудования, эксплуатируемого в сетях региональных операторов связи, с различными средствами технической эксплуатации и обслуживания;
• использование в сетях связи большого числа устаревших аналоговых систем, изначально не приспособленных для подключения к TMN;
• отсутствие встроенных в аппаратуру средств контроля функционирования и удаленного воздействия на систему;
• отсутствие у региональных операторов связи достаточных финансовых средств на
приобретение дорогостоящих программно-аппаратных платформ управления.
Для большинства традиционных телефонных сетей связи значительная доля коммутационного оборудования относится к унаследованным от до-TMN- овской эпохи, что в
принципе не позволяет реализовать полноценное управление. Для устаревшего оборудования в лучшем случае возможен только сбор информации аварийной сигнализации и
реализация некоторых сервисных функций, например «электронный замок» ( при наличии
соответствующих функций в подключённом оборудовании АПУС).
Для каждого оператора связи наиболее важным является обеспечение соответствующего уровня рентабельности, прибыльности, функциональности, управляемости, контролируемости, надежности эксплуатируемой им сети, а также уровня обслуживания и
оперативности устранения неисправностей. Поэтому в настоящее время операторы связи
нуждаются в едином сетевом управлении, которое ориентировалась бы на требуемое качество обслуживания, включая быстрое время восстановления оборудования связи после
сбоев, и одновременно учитывало бы организационную структуру оператора, характеристики его сети (топологию, оборудование и т.д.) и существующую инфраструктуру систем
управления. При внедрении современного комплекса сетевого управления, даже при наличии «трудно управляемого» устаревшего оборудования, оператор связи получает следующие преимущества:
• повышается качество услуг связи и обслуживания сети;
• оперативно обнаруживаются и устраняются неисправности;
• снижаются эксплуатационные расходы и появляются дополнительные доходы
за счёт качественно новых услуг [3], а это создает предпосылки для дальнейшего расширения и модернизации сети;
• оператор связи может контролировать альтернативных операторов, пользующихся той же сетью связи на правах присоединения;
• оператор связи может контролировать техническое состояние и работоспособность как отдельных узлов, так и всей сети;
• оператор связи получает возможность контролировать абонентские линии и
управлять потоками вызовов, анализировать трафик, а также принимать обоснованные решения по вопросу номенклатуры услуг, ценообразования и обслуживания сети.
Следует отметить, что успешное решение ряда перечисленных задач было осуществлено при создании в 1980-1990гг. Центров технической эксплуатации оборудования и
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

7

сетей связи, что позволило накопить достаточный практический опыт и усовершенствовать технологию удалённого контроля и управления телекоммуникационным оборудованием [2].
Необходимость создания централизованных систем управления сетями связи обусловлена и наметившейся в последнее время тенденцией укрупнения операторов связи как
в рамках одного региона, так и на межрегиональном уровне. В этом случае на первое место выступают задачи более высоких уровней управления (управление услугами и управление бизнесом), так как создаваемые объединения операторов должны работать в едином
пространстве предоставляемых услуг, иметь единую систему финансового и организационного управления. При создании межрегиональных компаний связи немаловажную роль
имеют задачи управления объединяемыми сетями связи для обеспечения более эффективного их взаимодействия. Подробнее вопросы бизнес- управления и управления услугами
рассматриваются в главе 7.
Итак, современные сети связи требуют организации комплексного сетевого управления [12], которое включало бы решение как задач автоматизации технической эксплуатации систем и сооружений связи, так и задач управления услугами, контроля качества
услуг связи, решение ряда бизнес-задач оператора. Эти задачи решаются с учётом основных положений концепции TMN, а применительно к ВСС РФ − в рамках создания автоматизированной системы управления операторов связи согласно руководящего документа
РД 45.174-2001 «Построение систем управления сетями связи операторов ВСС РФ». В последующих главах рассматриваются отдельные положения данной концепции, основные
протоколы сетевого управления, используемые современные информационные технологии.

1.2

Управление системой связи Российской Федерации

Сети связи, представляющие собой совокупность узлов и линий между ними,
предназначены для переноса (транспортировки) сообщений в виде электрических сигналов от источника сообщений к получателю. Для реализации услуг связи недостаточно
иметь оптимально построенные сети связи и соответствующее оборудование [7]. Необходимо создать вспомогательные службы, системы, надстройки над сетью связи, которые в
условиях расширяющихся запросов потребителей обеспечили бы ее устойчивое функционирование в течение всего срока существования, независимо от длительности срока службы аппаратуры и внешних дестабилизирующих воздействий.
К таким надстройкам относятся системы технической эксплуатации, нумерации,
тарификации, расчётов за услуги связи и ряд других. Полный перечень систем зависит от
конкретного вида сети связи (первичная, вторичная и т.д.). Совокупность этих систем
поддерживает транспортную сеть, обеспечивая ее функционирование и необходимый уровень показателей для удовлетворения требований потребителей (рис. 1.2). Перечисленные
«системы поддержки» объединяются общим понятием – система управления, которая неразрывно, в замкнутом контуре с обратной связью, взаимодействует с сетью электросвязи
через обусловленные интерфейсы.
Интерфейсы представляют собой устройства (программно-аппаратные средства)
для согласования технических средств системы управления, системы технической эксплуатации и сети связи.

Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

8

Система связи
Система управления
Система принятия решений
Интерфейс взаимосвязи
Подсистема
контроля

Подсистема
измерения

Подсистема
восстановления и
ремонта

Подсистема
резервирования

Подсистема
расчёта

Система технической эксплуатации

Интерфейс взаимосвязи

Сеть связи

Рис. 1.2 Система технической эксплуатации в составе системы связи (согласно [7])
Как уже отмечалось, сейчас в отрасли «Связь» роль управления в развитии и совершенствовании сетей значительно повышается. Если ранее управление понималось как
составная часть технической эксплуатации наряду с техническим обслуживанием, то в настоящее время, наоборот, управление рассматривается как более широкое понятие, включающее техническую эксплуатацию как составную часть. При таком подходе техническую эксплуатацию следует понимать как исполнительную составляющую системы
управления, которая средствами технического обслуживания обеспечивает в сети связи
выполнение тех решений и команд, которые приняты системой управления, и сообщает о
результатах их выполнения.
Иерархия организационных уровней управления, существующая для системы связи
Российской Федерации на ближайшую и отдалённую перспективу [1,4], представлена на
рис. 1.3.
В основе организации управления ВСС согласно РД по ВСС РФ [4,7] должны лежать следующие принципы:
• интеграция функциональных, физических и информационных структур управления;
• создание гибкой архитектуры на основе методологии открытых систем, обеспечивающей возможность реконфигурации и развития системы управления;
• стандартизация компонентов системы управления;
• высокий уровень автоматизации процессов управления;
• применение новейших технологий обработки информации.

Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

Макроуровень
управления

Микроуровень
управления

9
Министерство связи РФ и
соответствующие органы
управления и координации
Правительства России и
Федерального собрания
Территориальные и
региональные администрации
связи РФ; государственные и
негосударственные ассоциации,
концерны, АО и объединения
связи РФ
Государственные и
негосударственные предприятия
и учреждения связи РФ

Рис. 1.3 Иерархия организационных уровней управления связью
В качестве теоретической базы для построения системы управления ВСС принимается концепция сети управления электросвязью TMN, которая в общем виде изложена в Рек.
МСЭ-Т М.3010. Изложенный в данной рекомендации подход представляет основу для
интегрированного управления любыми по структуре, составу и объему сетями электросвязи.
В соответствии с Федеральным Законом «О связи» комплекс сетей электросвязи, входящих в состав ВСС, должен быть обеспечен централизованным управлением. Централизованное управление ВСС должно сочетаться с предоставлением операторам сетей самостоятельности в вопросах управления сетью и услугами связи в пределах их лицензионной
территории в повседневных условиях. Исходя из этого, система управления ВСС фактически представляет собой комплекс взаимоувязанных систем управления операторов сетей
связи общего и ограниченного пользования. Руководство и управление перечисленными
сетями связи в условиях чрезвычайной ситуации (положения), а также общая координация функционирования в повседневных условиях обеспечивается центральными органами
управления ВСС.
Основу комплекса составляют системы управления операторов сетей общего пользования. Эти сети охватывают территорию всей страны и обслуживают население, организации, учреждения народного хозяйства, а также других потребителей без каких-либо ограничений. При организации управления должна учитываться неравнозначность операторов, которые в зависимости от масштабности сетей и их государственной значимости делятся на операторов сетей связи федерального, зонального и местного значений ( рис. 1.4).
Принадлежность операторов к определенному классу обусловливает особенности
организационной структуры их систем управления, а также взаимодействие операторов между собой и с центральными органами управления.
В целом под системой управления сетью электросвязи понимается «система, выполняющая функции по управлению сетью на основе комплекса информационных технологий по
планированию, техническому обслуживанию, эксплуатации, оперативному и административному управлению сетями и предоставляемыми услугами» [7, с.44].
Организационно каждая система управления сетями (СУС) оператора должна представлять территориально - разнесенную иерархическую структуру, построенную в соответствии с
принципами TMN. Топология сетей управления в пределах зоны ответственности оператора,
размещение центров управления, число уровней иерархии должны (определяться в соответствии с
особенностями управляемых сетей, их назначением, размерами, разветвленностью, организацией технических средств.
Минимальное число уровней иерархии - два:
• на нижнем уровне находятся центры управления элементами сети (ЦУ-ЭС),
осуществляющие контроль и непосредственное взаимодействие с элементами
сети;
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

10

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

Системы управления операторов связи ОП

Национальны й
центр управления
ВСС РФ

Центр управления
сетью федеральный

Региональны й
центр управления
ВСС РФ

ТЦУфедеральный

Зональны й центр
управления
ВСС РФ

Центр управления
сетью - зональный

Узловой центр
управления федеральны й

М естный центр
управления
ВСС РФ
Центр управления
элементами сети зональны й

Центр управления
элементами сети зональны й

Центр управления
элементами сети зональны й

Центр управления
элементами сети федеральны й

Рис. 1.4. Структурно-функциональная схема управления для операторов сетей общего пользования (по материалам [6])
Системы управления сетями операторов зонального значения должны иметь трехили двухуровневую структуру. Системы управления сетями операторов местного значения, как правило, должны иметь двухуровневую структуру управления.
Системы управления оператора могут включать ряд подсистем управления различными
видами сетей связи в зоне данного оператора.
Каждая СУС оператора должна иметь единый многофункциональный головной
центр управления сетями (ЦУ оператора), который должен осуществлять контроль за состоянием сетей зоны оператора в целом, планирование развития сетей и предоставления услуг связи,
взаимодействие с центрами управления других операторов и соответствующими центральными
органами управления.
Итак, структура управления ВСС РФ и операторов связи представляет собой сложную
многоуровневую структуру с многообразными функциональными связями на всех уровнях.
Создание и обеспечение работоспособности рассмотренной структуры требует не только организационно-технических, но управленческих решений по реорганизации управления предприятием
связи (оператором) в целом. Это более высокий уровень управления, описание которого возможГлава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

11

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

1.3

Понятие о функциональном менеджменте связи

Понятие менеджмента в современной интерпретации многозначно. В современном
управлении используются различные смысловые трактовки функционального менеджмента. В применении к условиям связи РФ наиболее полная и ёмкая из них приведена на
рис.1.5 [1].

Функциональный
менеджмент
связи

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

Рис. 1.5 Определение функционального менеджмента связи (источник [1])
Применение на практике принципов функционального менеджмента обеспечивает
постоянное совершенствование управления отраслью связи РФ. Это необходимо по следующим причинам:
• старые, привычные методы и приёмы функционального управления не всегда срабатывают эффективно; принципиально изменились время, обстоятельства, условия и ограничения, цели деятельности связи РФ;
• без современной системы функционального управления невозможна интеграция связи
РФ в мировое телекоммуникационное пространство.
Для увеличения общей эффективности управления, повышения ответственности на
каждом уровне за принятие и исполнение управляющих решений в рамках концепции
функционального менеджмента могут быть предложены следующие методы:
1. Трансформация организационной пирамиды в более плоскую структуру с меньшим
количеством уровней управления. Современная теория организаций делает акцент на
трех принципах: простота и компактность формы, малые размеры, ориентация на людей.
2. Интеграция управления с человеческими ресурсами и долгосрочной стратегией развития.
3. Использование новых подходов к теории управления, что на практике означает движение от теорий административного и корпоративного управления к теории партисипативного управления на принципах участия.
Для применения в рамках системы сетевого управления наиболее важными являются методы 1 и 2, применение которых предусматривает сплошную информатизацию и
автоматизацию процессов управления, обеспечение доступности управляющей информации для пользователей. Решение перечисленных задач достигается за счёт применения
средств технического обеспечения процессов управления.
Состав и структура комплекса технических средств системы функционального менеджмента связи в общем виде показана на рис. 1.6.

Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

12

Комплекс
технических
средств
функционального
менеджмента

Средства сбора
и регистрации
управленческих
данных

Системы и
средства
передачи
управленческой
информации

Системы и
средства
обработки
управленческой
информации

Системы и средства
подготовки и
принятия
управленческих
решений

Рис. 1.6 Состав и структура технического обеспечения системы функционального менеджмента связи (источник [1])
Основные требования, предъявляемые к системам и средствам технического обеспечения функционального менеджмента связи, и следовательно, к средствам сетевого
управления таковы:
• надежность (достоверность данных);
• оперативность (своевременность доставки сообщений);
• быстродействие (в заданных пределах);
• высокое качество передачи и обработки данных управления.
Целью функционирования комплекса технических средств управления является
повышение эффективности функционального менеджмента связи. Поэтому в основе организации комплекса технических средств управления должны лежать следующие принципы:
• централизация управления с возможной децентрализацией функций управления;
• интегрированный подход к решению задач управления сетями связи в пределах общей
территории;
• создание гибкой архитектуры на основе методологии открытых систем, обеспечивающей возможность реконфигурации и наращивания функций управления;
• обеспечение высокого уровня автоматизации процессов управления и применение новейших методов обработки информации;
• использование единой системы стандартов по техническому, информационному и программно-алгоритмическому обеспечению на базе рекомендаций МСЭ-Т, стандартов
ETSI, ISO, ГОСТ, а также отраслевых стандартов.
Итак, основной целью внедрения системы функционального менеджмента должно
стать обеспечение эффективной работы всего комплекса подразделений и предприятий
оператора связи. Эта цель достигается за счёт трансформации организационной структуры, интеграции управления с человеческими ресурсами на основе применения комплекса
технических средств и информатизации организаций связи. Программно-аппаратный комплекс управления обеспечивает всестороннюю информатизацию и автоматизацию процессов управления, в том числе с учётом перспективного развития телекоммуникаций.
Направления этого развития обсуждаются в следующем разделе.

Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

1.4

13

Услуги и управление в глобальной информационной инфраструктуре GII

Глобальная информационная инфраструктура (global information infrastructure, GII)
[8,9] позволяет людям пользоваться услугами телекоммуникаций. Основой GII являются
существующие и строящиеся телекоммуникационные системы и сети. Для предоставления услуг телекоммуникаций в GII используются многочисленные программноаппаратные средства, которые позволяют пользователям обмениваться любыми видами
сообщений (речь, видео, данные) в любое время по приемлемой цене и с заданным качеством. Средства GII позволяют унифицировать процедуры предоставления доступа к услугам связи для жителей различных государств, а также организовать межсетевое взаимодействие сетей связи различных стран. ВСС РФ является частью GII.
Концептуально GII включает в себя 4 основных элемента:
• люди, которые являются источниками и получателями сообщений, используют информацию;
• информационные устройства (information appliances), которые используются для хранения, обработки данных и обеспечивают доступ к информации;
• коммуникационная инфраструктура, которая осуществляет передачу информации между географически удалёнными информационными устройствами. Информационная
инфраструктура может быть представлена в виде транспортной сети и сети доступа;
• собственно информация, которая включает в себя прежде всего видеоинформацию,
речь, данные, а также прикладное программное обеспечение (пользовательские приложения), которые позволяют конвертировать сообщения из оригинальной формы (с,
изображение, компьютерная графика) в электронную форму, доступную для использования другими пользователями GII.
Взаимодействие перечисленных элементов показано на рис. 1.7.

Информация
Платформа
поддержки
приложений

Информация

Протоколы обмена

Платформа
поддержки
приложений

Платформа
поддержки
коммуникаций

Телекоммуникационная сеть
(сети связи)

Платформа
поддержки
коммуникаций

Информационные
уст ройст ва

Телекоммуникационная
инфраструктура

Информационные
уст ройст ва

Рис. 1.7. Взаимодействие основных элементов GII
Примеры информационных устройств – персональный компьютер, сетевой компьютер, телефонный аппарат, телевизионный приёмник, факсимильный аппарат, персональный цифровой помощник и т.п.
В качестве платформы поддержки приложений могут использоваться вычислительные средства в совокупности с операционными системами, микропрограммное обесГлава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

14

печение информационных устройств, прикладное программное обеспечение, специализированные процессоры и кодеки.
Платформы поддержки коммуникаций – это оконечное оборудование данных, модемы, устройства доступа различного назначения. Примеры средств доступа – абонентская линия связи до АТС, линия DSL-доступа, сеть кабельного телевидения, оптическая
линия доступа, канал радиосвязи, спутниковый канал, линия радиодоступа. Примеры телекоммуникационных сетей – телефонная сеть связи общего пользования, первичная сеть
связи, сеть передачи данных различных стандартов (X.25, Frame Relay, ATM, MPLS), сеть
Интернет. Все перечисленные программные и аппаратные компоненты GII, а также услуги, оказываемые на их основе, являются объектами сетевого управления.
Структура GII связывает между собой в единое целое сетевые ресурсы, устройства
хранения и обработки данных, а также ресурсы промежуточного программного обеспечения (middleware) для того, чтобы предложить пользователям стандартные услуги и поддержать приложения пользователя. К средствам middleware в рамках GII можно отнести
средства обеспечения информационной безопасности, биллинг, а также средства сетевого
управления и администрирования. Средства middleware могут быть одновременно доступны не только индивидуальным пользователям, но и достаточно большим группам абонентов. Не участвуя непосредственно в преобразовании информации из одной формы в
другую, средства middleware позволяют регулировать этот процесс, обеспечивая оптимальное распределение, защищенность и управляемость сетевых ресурсов.
Услуги телекоммуникаций и приложения пользователей строятся из отдельных
компонентов, которые называются «блоками построения» (building blocks). Наличие тех
или иных компонент определяет свойства и возможности ресурсов.
В рамках GII услуги телекоммуникаций характеризуются транзакциями, т.е. одной
или несколькими взаимосвязанными операциями с информацией или данными, которые
осуществляет пользователь при запросе/активизации услуги. При этом приложения пользователя позволяют получить полные права по использованию данной услуги. Например,
установка программы почтового клиента на компьютер позволяет пользователю воспользоваться услугами электронной почты (разумеется, если пользователь имеет соответствующую авторизацию и доступ к почтовой службе, что обеспечивается middleware). При
этом данная программа имеет соответствующий пользовательский интерфейс (графическое изображение на дисплее), который позволяет пользователю практически пользоваться услугой. Пользовательский интерфейс можно рассматривать в самом широком смысле.
Например, радиотелефон в системе подвижной связи также можно рассматривать как интерфейс пользователя, который, являясь информационным устройством, поддерживает
пользовательские приложения (электронная телефонная книга) и средства коммуникаций
(цифровое кодирование и передача речи).
Клиенты могут воспользоваться услугами GII напрямую или с помощью пользовательских приложений. При этом компоненты пользовательских приложений должны поддерживаться в GII. Компоненты приложений и услуг GII могут объединяться в пакеты,
чтобы создать для пользователя требуемую услугу или предоставить доступ к приложению. Общая структура услуг информационной системы в рамках GII показана на рис. 1.8.

Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

15

Услуги IP-телефонии, службы передачи данных,
интеллектуальные сети, службы Интернет

Услуги
инфраструктурного уровня
(телесервисы , службы связи)

Услуги
промежуточного
уровня (m iddlew are)

Биллинг

Безопасность

Поиск
данных

Аутентификация

Обмен данными
Услуги
базового уровня
(сети связи,
приложения
пользователя)

ТФОП

Телекоммуникационная сеть
АТС

Сеть доступа

Передача речи

М одем
Сеть доступа

e-m ail

Информационны е

IP-сеть

Коммутатор
Сеть доступа

Кабельное ТВ
уст ройст ва

Рис. 1.8. Уровни услуг сети связи следующего поколения (по материалам [8,10])
Традиционные операторы телефонной связи, как правило, предлагают пользователям технологии для доступа к новым услугам (за исключением базовых услуг связи), в то
время как информационная индустрия предлагает пользовательские приложения для доступа/организации услуг. В перспективе, вероятно, будет осуществлена конвергенция этих
элементов, так как уже сегодня получить доступ к большинству новых услуг связи невозможно без пользовательских приложений (Интернет−браузеров, почтовых программ,
приложений для кодирования и передачи речи по IP−сетям).
Спектр услуг, которые предлагаются в рамках GII, достаточно широк и может динамически меняться вместе с изменением доступных ресурсов. Поэтому зачастую целесообразно классифицировать компоненты услуг, нежели сами услуги. При этом каждый
компонент услуги зависит от ресурса, необходимого для ее поддержки. Различают несколько компонентов услуги.
Инфраструктурные компоненты услуги (infrastructural service components) предоставляют доступ к конечным информационным услугам (службам, телесервисам), для передачи речи через телефонную сеть, пересылки файлов данных через Интернет и т.п. Инфраструктурные компоненты также могут включать услуги компонент промежуточного и
базового (baseware) уровня программного управления.
Компоненты услуг промежуточного (middleware) уровня используются прежде всего для обеспечения межсетевого взаимодействия и совместного функционирования нескольких приложений. Они позволяют объединять компоненты услуг базового уровня и
поддерживать инфраструктуру, которая необходима для предоставления всего набора услуг. Как правило, компоненты услуг, которые могут быть предоставлены конечному
пользователю на коммерческой основе, включают в себя описания способов продажи этих
услуг, способы учёта использования услуг, средства мониторинга и описание уровней качества услуги.
Существует 4 категории услуг промежуточного уровня.
Категория M1 – компоненты пакетизации и взаимодействия услуг. Обеспечивают
возможность объединения в пакет ряда инфраструктурных услуг, поддерживают взаимодействие между различными системами GII.
Категория M2 – компоненты поддержки услуг промежуточного ПО. Применяются
для обеспечения коммуникационной функции GII и включают компоненты услуг:
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи







16

человеко-машинного интерфейса;
регистрации пользователя;
аутентификации;
обеспечения информационной безопасности;
поиска информации;
биллинга;
управления услугами.

Как будет показано в главах 3,7,9, многие из перечисленных компонентов услуг
относятся к сетевому управлению [10].
Категория M3 – поддержка компонентов для создания услуг или пользовательских
приложений. Эти компоненты, как правило, являются специфичными для той или иной
системной программно-аппаратной платформы или типа средств связи.
Категория M4 - компоненты услуг, предназначенные для обеспечения межсетевого
взаимодействия и поддержки распределённых приложений. Распределённые приложения
функционируют на различных информационных устройствах, поддерживающих компоненты базового уровня. Сюда же относятся услуги конвертации сообщений и файлов из
одного формата в другой. Существует несколько подходов к определению категории услуг М4. Международная неправительственная группа Object Management Group (OMG)
предлагает использовать для описания взаимодействия между услугами специальный
язык общего описания интерфейсов (common interface definition language), который называется CORBA IDL. Этот язык обеспечивает трансляцию определения одной услуги в определение другой услуги. Подробнее об использовании принципов CORBA для управления сетями связи рассказывается в Главе 7. Услуги категории М4 относятся также к задачам сетевого управления.
Компоненты услуг базового уровня (базового программного обеспечения) поделены между компонентами услуг сетей связи и компонентами услуг обработки и хранения
данных. Соответственно, компоненты услуг связи используют сетевые ресурсы, а компоненты услуг сбора и хранения информации - ресурсы систем хранения и обработки данных (центры обработки и хранения данных).
Компоненты услуг базового уровня поддерживают функции, которые в свою очередь обеспечивают компоненты услуг высшего уровня. Поэтому услуги базового уровня
охватывают все виды телекоммуникационных сетей, устройства/платформы хранения и
обработки данных. Компоненты услуг базового уровня делятся на три категории.
К первой категории (B1) относятся компоненты транспортировки/передачи информационных услуг. К данным компонентам относится:
• передача данных от интерфейса до интерфейса (имеются в виду одинаковые сетевые интерфейсы, которые территориально находятся в различных сетях);
• передача сообщений, которые требуются для поддержки компонентов услуги
категории B3.
В рамках GII необходимы компоненты для глобальной передачи данных, речи и
видео. Этими компонентами являются сети связи различного назначения, которые в перспективе будут интегрированы в единые конвергентные транспортные сети, например на
основе технологии ATM.
Категория B2 включает компоненты услуг обработки и хранения информации. Эти
компоненты включают установку, вызов и обработку компонентов приложений для ответа на запросы других приложений. Кроме того, компоненты категории B2 обеспечивают
хранение данных в устройствах памяти и выполнение заданий процессорами. Компоненты услуг категории B2 доступны через прикладные программные интерфейсы (Application
Program Interface, API). Следует отметить, что полная и всесторонняя спецификация, т.е.
детальное описание API и соответствующих компонентов услуг, достаточно сложна. Различают API UNIX, Java, ActiveX, WIN32.
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

17

Компоненты услуг категории В3 осуществляют контроль и управление функциями
поддержки компонентов услуг категорий B2 и B3. Компоненты категории B3 выполняют:
• управление последовательностью операций на информационных устройствах;
• сохранение файлов и операции восстановления информации;
• установление и поддержку соединений, управление сеансом обмена данными;
• управление базовыми услугами передачи, обработки и хранения данных.
Итак, среди компонентов услуг как промежуточного, так и базового программного
обеспечения имеются услуги управления. При этом для базового уровня характерна «приближённость» услуг к функционированию в реальном времени, т.е. оперативнотехническое управление соединением на уровне организации оконечных сетевых соединений или сеансов связи.
Логика управления на промежуточном уровне носит более общий характер и затрагивает вопросы контроля качества услуг связи, обеспечение информационной безопасности, обеспечение межсетевого взаимодействия. Интерфейсы взаимодействия между функциями управления и другими функциями GII рассматриваются далее.

1.5

Функции и логические интерфейсы управления в GII

Функция – это некий логический элемент (реализуемый на практике программноаппаратными средствами), который выполняет заранее определённое задание в ответ на
появление входного сигнала; в результате действия функции появляется определённый
выходной сигнал или информация. Функции осуществляются телекоммуникационными
устройствами. Одна и та же функция, например установление исходящего соединения,
может осуществляться телекоммуникационными устройствами различных видов и типов.
Подробнее о функциях сетевого управления говорится в разделах 6.1 и 7.1.
Логический интерфейс – это полностью описанная процедура взаимодействия между двумя функциями, включая формат информации, которая передаётся между функциями и описание отклика на передачу информации. С точки зрения технического устройства, которое реализует ту или иную функцию, отклик означает срабатывание этого устройства. В описание логического интерфейса также включается описание протокола взаимодействия и функциональной опорной точки (functional reference point) обмена информацией. Протокол содержит описание входных/выходных сигналов и последовательности
обмена ими. Функциональная опорная точка определяет, что именно доступно в данной
функции (какие данные доступны) при внешнем обращении к ней.
Функции, логические интерфейсы в совокупности составляют функциональную
модель GII. Функциональные модели (рис. 1.9) широко применяются в телекоммуникационных и информационных технологиях в связи с тем, что они позволяют разработчикам
ответить на один из основных вопросов: как будет функционировать тот или иной элемент
GII и какие функции этот элемент будет выполнять. При этом функциональная модель не
зависит от той или иной информационной или телекоммуникационной технологии. Существует несколько методологий функционального моделирования:

использование модели распределённых вычислений ODP (см. главу 7);

использование независимых блоков построения услуг (Service Independent Building
blocks, SIB) в интеллектуальных сетях;

использование понятия «функциональный блок» при описании телекоммуникационного оборудования.

Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

18

Форматы информации
Протокол взаимодействия
Ф ункция

Ф ункция

Рис. 1.9. Функциональная модель
По «форматом информации» на рис. 1.9 понимается способ кодировки данных в
том или ином протоколе, в частности, уже упомянутый язык CORBA IDL, HyperText
Markup Language (HTML), форматы сигнальных единиц в общеканальной сигнализации
ОКС№7, форматы кодирования речи и видеоизображения.
В GII существуют следующие основные виды функций.
Функции приложений (Applications Functions, AF) – описание прикладных задач
пользователя, в частности прикладных задач управления.
Функции промежуточного уровня (Middleware Functions, MF) – описание задач,
которые решаются программами прикладного уровня:
• функции контроля услуг (Service Control Functions, SCF) позволяют создавать
услуги из отдельных компонент и назначенных для услуг сетевых ресурсов;
здесь же присутствуют функции контроля за взаимодействием пользователя и
услуги. Как отмечалось выше, это функции контроля нижнего уровня, например, это может быть контроль исправности абонентской линии или времени
набора телефонного номера. Эти функции могут реализовываться на уровне
программного обеспечения оборудования связи;
• функции управления (Management Functions, ManF),которые реализует задачи
управления всеми другими функциями.
Функции базового уровня (Baseware Functions, BF) позволяют прикладным функциям и функциям промежуточного уровня действовать, обмениваться сообщениями с другими функциями, используя для этого сетевые функции, и организовывать интерфейс
(точки взаимодействия) с пользователями. Функции базового уровня включают в себя:
• сетевые функции (Network Functions, NF),которые поддерживают обмен сообщениями, т.е. коммуникативность между различными объектами GII, и включают в себя транспортные функции (Transport Functions, TF) и функции контроля (Control functions, CF);
• функции обработки и хранения информации (Processing and Storage Functions,
P&SF), которые обеспечивают работу компонентов промежуточного уровня и
приложений, а также сохраняют информацию;
• функции интерфейса человек-машина (Human-Computer Interfacing Functions,
HCIF), которые позволяют приложениям обмениваться информацией с пользователем.
Перечисленные функции могут, в свою очередь состоять из специализированных
функций. В частности, в дополнение к функции переноса информации и функции программного управления узлами связи могут существовать дополнительные функции
управления, например функции поддержки управления узлами интеллектуальных сетей
или узлами программной коммутации (softswitch). Оператор связи должен использовать
следующие сетевые функции:
• транспортная функция (или функция переноса, transport functions), которая позволяет передавать информацию между разнесёнными в пространстве узлами;
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

19

функция поддержки управления телекоммуникационным оборудованием
(control functions), которая обеспечивает маршрутизацию информации между
исходным узлом и узлом назначения;
• усовершенствованная функция предоставления услуги (enhanced service
provisioning functions), которая обеспечивает возможность предоставления и
контроля услуг интеллектуальных сетей, а также других новых услуг связи;
• функция сетевого управления (management functions), которая используется для
управления другими функциями оператора связи.
Следует отметить, что многие прикладные функции могут многократно использоваться многими новыми приложениями, что приводит к их постепенной миграции в направлении функций промежуточного уровня. Это может в полной мере относиться и к
функциям сетевого управления, например, когда формирование требуемого пакета услуг
для различных пользователей осуществляется с помощью одинаковых функций, вызываемых с помощью информационных устройств пользователя.
С учётом многообразия функций GII, существует несколько типов логических интерфейсов между различными типами функций:
• прикладной протокол (Application Protocol, AP) − логический стык между прикладными функциями;
• прикладной программный интерфейс (Application Programming Interface, API)−
логический интерфейс между прикладными функциями и функциями промежуточного уровня, которые поддерживают прикладные функции;
• протокол промежуточного уровня (Middleware Protocol, MP) − логический стык
между функциями прикладного уровня;
• базовый программный интерфейс (Basic Programming Interface, BPI) − логический интерфейс между функциями промежуточного уровня и функциями базового уровня, которые поддерживают функции промежуточного уровня (часто
эти интерфейсы относятся к API);
• интерфейс человек−компьютер, или человеко−машинный интерфейс (HumanComputer Interface, HCI) − логический интерфейс между пользователем и, главным образом, функциями базового уровня; это не исключает возможности человеко−машинного интерфейса с функциям промежуточного уровня и с прикладным функциям;
• опорная точка сетей связи (Telecommunications Reference Point, TRP) − логический интерфейс между функциями базового уровня и сетевыми функциями.
На рис. 1.10 показаны функции управления различного уровня, взаимодействующие через соответствующие интерфейсы.
Интерфейсы 1, 9 соответствуют опорным точкам транспортных функций, которые «прозрачны» для поддержки других логических интерфейсов, включая прикладные
протоколы, протоколы промежуточного уровня, и функции контроля (оперативного управления) между функциями базового уровня и функциями сетевого контроля (network control functions).
Интерфейс 2 соответствует опорным точкам транспортных функций, которая обеспечивает обмен информацией между функцией сетевого контроля и функцией базового
уровня, а также функциями управления услугами.
Интерфейс 3 соответствует опорным точкам транспортных функций, которые «прозрачны» для всех типов протоколов.
Интерфейс 4 соответствует опорным точкам между функциями базового уровня и
функциями оперативного управления сетью (контроля сети), которые позволяют
предоставлять услуги связи и независимы от технических средств реализации
транспортной функции.
Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

20
10

Функции управления

Функции управления

5

5

Функции базового
и промежуточного
ПО

9

Функции базового
и промежуточного
ПО

8

1

6

Функции управления
оборудованием в
реальном времени

3

Функции управления
услуг связи в реальном
времени

2

4

Транспортные функции

Функции
базового и
промежуточного
ПО

5

Транспортные функции

7
Функции
базового и
промежуточного
ПО

Прикладные
функции

Приклданые
функции

Пользователь

Рис. 1.10. Примеры функций и логических интерфейсов в GII [8]
Интерфейс 5 соответствует опорным точкам сетевого управления, которые имеют множество реализаций, осуществляют управление всеми функциями и независимы от
транспортной функции.
Интерфейсы 6, 7, 8 реализуются с помощью протоколов промежуточного уровня, которые
прозрачны для сетевых функций.
Интерфейс 10 соответствует протоколу сетевого управления (management protocol). Осуществляет обмен данными между функциями сетевого управления.
Итак, в функциональной модели GII обозначены опорные точки и соответствующие интерфейсы управления. При этом функции управления распределены между функциями базового и промежуточного программного обеспечения. В то же время необходимо организовать взаимодействие между функциями управления и транспортными функциями, так как в противном случае будет потеряна управляемость транспортной (телекоммуникационной) сетью связи. Следовательно, для реализации задач сетевого управления в рамках ВСС как составной части GII необходимы опорные точки и интерфейсы различного назначения, которые позволяют реализовать следующие виды взаимодействия:
• взаимодействие внутри GII от функций управления через функции базового и
промежуточного уровня к функциям транспортной сети;
• взаимодействие пользователя и GII;
• взаимодействие между различными функциями управления.
О том, как реализуются перечисленные функции, опорные точки и интерфейсы см.
глав 3, 6 и 9.

Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

21

Список источников к главе 1.
1. Булгак В.Б., Варакин Л.Е и др. Концепция развития связи Российской Федерации. −
М.: Радио и связь, 1995.
2. Даленбах Д., Мирошников Д.Г. Единая система технической эксплуатации сети связи
// Вестник связи − 1996 г. − №12 − С. 23-27.
3. Князев К.Г. Система управления сетью как источник новых доходов // - Вестник связи.
− 2001. − №1. − C. 26 − 29.
4. Основы управления связью Российской Федерации/ В.Б. Булгак, Л.Е. Варакин, А.Е.
Крупнов и др.; Под ред. А.Е. Крупнова и Л.Е. Варакина. − М.: Радио и связь, 1998.
5. Приказ Министерства связи Российской Федерации № 134 “О мероприятиях по созданию системы управления ВСС РФ" от 30.11.1996 г.
6. Основные положения развития Взаимоувязанной сети связи Российской федерации на
перспективу до 2005 г. Руководящий документ. Книга 1. − М., ЦНТИ «Информсвязь»,
1996 г.
7. Основные положения развития Взаимоувязанной сети связи Российской федерации на
перспективу до 2005 г. Руководящий документ. Книга 8. − М., ЦНТИ «Информсвязь»,
1996 г.
8. ITU−T Recommendation Y.110. Global Information Infrastructure principles and framework
architecture. − 1998.
9. ITU-T GII Standartization Initiative. Technical information bulletin 99-5. Режим доступа :
[http://www.ncs.gov/n2/content/tibs/files/tib99_5.pdf. 28.08.02]
10. OSS Solutions for Network Operators. White paper, 2002. Режим доступа :
[http: //www.ausystem.se/publications/OSSwp0501.pdf 27.08.2002]
11. Pavlou G. Telecommunications Management Network: a Novel Approach Towards its Architecture and Realisation Through Object-Oriented Software Platforms/ PhD thesis. Режим
доступа : [ftp://cs.ucl.ac.uk/osimis/papers/phd-gp/02-contents.pdf 14.02.2001]
12. Proposed Focused Program on: Operations and Management of Information Networks // National Institute of Standards and Technology Advanced Technology Program. – 1994. Режим
доступа : [www.cs.columbia.edu/dcc/classes/E6998-025/References/atpwpf.ps 3.09.02]

Глава 1 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

22

2. УПРАВЛЕНИЕ ОТКРЫТЫМИ СИСТЕМАМИ

2.1

Открытые системы и их взаимодействие

Сетевое управление ВСС РФ, согласно книги 1 РД по ВСС РФ, строится с учётом
основных положений концепции сети управления электросвязью (TMN). Концепция
TMN в общем виде изложена в Рек. МСЭ-Т М.3010. Детальное описание стандартов и
технологий TMN содержится в остальных рекомендациях МСЭ-Т серии M.3xxx, начиная с Рек. M.3000 и заканчивая Рек. M.3660 (см. Приложение 1). Концепция TMN,
предложенная МСЭ-Т, представляет собой методологическую основу для организации
интегрированного управления сетями связи с разнообразной структурой, составом оборудования, объемом передаваемых данных, типами нагрузки и т.п.
В свою очередь, концепция TMN основана на семиуровневой модели взаимодействия открытых систем (ВОС), которая была стандартизована международной организацией по стандартизации МСО (International Standard Organizaton, ISO). Концепция
TMN является своеобразной «действующей силой», позволяющей учитывать особенности модели взаимодействия открытых систем в телекоммуникациях. В дальнейшем
ссылки на принципы построения семиуровневой модели ВОС будут достаточно частыми, поэтому перед тем, как обратиться к проблемам сетевого управления, в настоящей
главе приводятся необходимые сведения о модели ВОС.
Существуют несколько определений понятия «открытая система», которые в
разное время были сформулированы такими организациями, как Институт инженеров
по электротехнике и электронике (Institute of Electrical and Electronics Engineers,
IEEE), Национальный институт по стандартам и технологиям США (National Institute of
Standards and Technology, NIST), компанией Hewlett-Packard. С учётом материалов российской межотраслевой программы «Развитие и применение открытых систем» [4] в
качестве определения можно использовать следующую трактовку понятия «открытых
систем», которую дал комитет IEEE POSIX 1003.0:
«Открытая система - это система, реализующая открытые спецификации на интерфейсы, службы и форматы данных, достаточные для того, чтобы обеспечить:
• возможность переноса (мобильность) прикладных систем, разработанных должным
образом, с минимальными изменениями на широкий диапазон систем;
• совместную работу (интероперабельность) с другими прикладными системами на
локальных и удаленных платформах;
• взаимодействие с пользователями в стиле, облегчающем последним переход от системы к системе (мобильность пользователей)».
Открытая система есть абстрактное описание физических объектов. Поэтому
открытая система может быть представлена любым типом телекоммуникационного
оборудования – АТС, маршрутизатором, сервером доступа в Интернет, абонентским
терминалом и т.п. Все перечисленные устройства можно рассматривать как открытые
системы, если они удовлетворяют приведённому определению.
Ключевой момент в определении открытых систем – использование термина
«открытая спецификация». Здесь и далее под «спецификацией» понимаются требования, предъявляемые к системе [3]. Спецификация включает упорядоченное описание
параметров и структуры объекта или интерфейса; в таком описании обязательно присутствует определение основных терминов, используется определённый метод описания объекта и содержатся указания на взаимосвязь данного объекта с другими объектами. Открытая спецификация определяется [4] как «общедоступная спецификация,
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

23

которая поддерживается открытым, гласным согласительным процессом, направленным на постоянную адаптацию новой технологии, и соответствует стандартам». Отсюда следует, что спецификация, к примеру, того или иного интерфейса для управления
сетями связи вводят безотносительно к конкретным программно-техническими средствам реализации этого интерфейса. Данный вопрос подробно обсуждается в главе 6, где
рассматриваются различные интерфейсы сетевого управления.
Как следует из определения, сущность технологии открытых систем состоит в
обеспечении переносимости (portability) прикладных программ между различными
компьютерными платформами или устройства телекоммуникаций при сохранении
взаимодействия (interoperability) таких систем друг с другом. Технически это достигается за счет использования стандартизованных программных и аппаратных интерфейсов между компонентами (уровнями) открытых систем.
Работы по организации и стандартизации взаимодействия открытых систем постоянно ведутся как на уровне крупнейших производителей вычислительных средств и
телекоммуникаций (Hewlett-Packard, IBM, Sun Microsystems и др.), так и на уровне правительственных организаций. Ведущее место в области стандартизации открытых систем принадлежит Совместному техническому комитету СТК-1 (Join Technical Committee JTC-1) «Информационная технология» в составе ISO, а также Международной электротехнической комиссии (International Еlectrotechnical Сommission, IEC) и Международному союзу электросвязи, МСЭ (International Telecommunication Union, ITU). Следует отметить, что в 1995 г. в мире насчитывалось более 1000 международных стандартов по информационным технологиям (в России таких стандартов более 80), поэтому
модель ВОС является методологической базой для многочисленных разработок.
Стандартизация взаимосвязи систем охватывает три уровня описания средств
информационного обмена. На первом уровне специфицируется эталонная модель взаимодействия открытых систем, в рамках которой определяются основные понятия и общая структура взаимосвязи, описываются принципы построения системы базовых
стандартов, т.е. определяются язык описания и методологические основы построения и
описания стандартов ВОС.
На втором уровне определяются спецификации сервиса (услуг), предоставляемого отдельными компонентами модели ВОС, т.е. на данном уровне стандартизуются
функциональные возможности уровней модели.
Третий уровень описания является наиболее детальным. На этом уровне осуществляется спецификация протоколов информационного обмена между функциональными элементами эталонной модели, определяющими правила и форматы взаимодействия элементов.
С позиций перечисленных уровней модель ВОС, обозначаемая в англоязычной
литературе как ISO/RM (Open System Interconnected / Reference Model), на сегодняшний
день является достаточно проработанной с точки зрения функциональности, полноты
набора стандартов, определения совместимости стандартов друг с другом. Модель основана на разбиении среды на семь уровней (рис. 2.1). Каждый уровень соответствует
подсистеме с определёнными функциями обработки информации [2,4-6].

Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

Открытая система А

Область взаимодействия открытых систем

Прикладной
уровень

Сущность

SAP
Представительный уровень Сущность
Сеансовый
уровень
Транспортный
уровень
Прикладной
уровень

SAP
Сущность
SAP
Сущность
SAP
Сущность
SAP

Канальный
уровень

Сущность
SAP

Физический
уровень

Сущность

24

Ассоциация между
сущностями

Открытая система Б

Протокол
прикладного
уровня

Сущность

Протокол
представительного
уровня

Сущность

Протокол
сеансового
уровня

Сущность

Протокол
транспортного
уровня

Сущность

Протокол
сетевого
уровня

Сущность

Протокол
канального
уровня

Сущность

Протокол
физического
уровня

Сущность

Прикладной
уровень

SAP

Представительный уровень

SAP

Сеансовый
уровень

SAP

SAP

SAP

Транспортный
уровень
Сетевой
уровень
Канальный
уровень

SAP
Физический
уровень

Физическая среда распространения
Межсистемное взаимодействие

Рис. 2.1 Модель взаимодействия открытых систем ISO/RM
На прикладном уровне (application layer) работают приложения, с которыми
имеет дело пользователь, например, выполнение вычислительных задач, поиск сведений в базе данных или в каталогах и т.п. Этот уровень не предоставляет своих услуг
другим уровням модели ВОС. На прикладном уровне осуществляется взаимодействие
прикладных процессов.
На уровне представления (presentation layer) обеспечивается возможность перекодировки информации прикладного уровня в единый формат, который принят в данной системе обмена. На этом уровне, при необходимости, осуществляется шифрование
данных.
На сеансовом уровне (session layer) организуется диалог между уровнями представления, т.е., по сути, диалог (сессия, или сеанс) между прикладными задачами высшего уровня; на этом же уровне осуществляется управление сессией и ее прерывание.
На транспортном уровне (transport layer) осуществляется разбиение данных на
пакеты с целью последующей передачи в узлы назначения. При этом передача сообщения от сеансового уровня на транспортный осуществляется через точку доступа к услуге (Service Access Points, SAP), которая называется также портом. Каждый порт имеет
свой номер; начало сеанса связи означает занятие порта в исходящем узле, а о наличии
соединения свидетельствует занятый порт на входящем узле.
На сетевом уровне (network layer) осуществляется соединение двух открытых
систем с выбором маршрута установления соединения через сеть связи, соединяющей
эти системы. Выбор маршрута может осуществляться с помощью специальных пакетов
данных или самим пакетом.
На уровне канала данных (data-link layer) осуществляется передача данных через
канал связи или канал передачи. При этом к пакету могут быть добавлены служебные
поля для обеспечения физической адресации, контроля целостности данных; в качестве
служебной информации добавляется порядковый номер, а также биты, разделяющие
пакеты. В итоге формируются кадры, которые поступают на физический уровень. ПеГлава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

25

речисленные функции канального уровня могут быть физически реализованы на сетевом интерфейсном модуле/карте (Network Interface Card, NIC).
На физическом уровне (physical layer) осуществляется физическое соединение
узлов сети при побитовой передаче кадров между узлами. Данный уровень определяет
тип среды передачи, кодирование данных, методы передачи.
Физическая среда распространения обеспечивает перенос электрического или
оптического сигнала (по медным или оптическим кабелям связи, радиоэфиру и т.п.).
Разбиение на уровни обеспечивает «прозрачность» взаимодействия между
уровнями как внутри данной системы, так и между уровнями различных открытых систем. Поэтому модель ВОС в большей степени относится к области коммуникационных
взаимодействий между различными системами и детально не рассматривает взаимодействие элементов «внутри» данной системы. Коммуникационное взаимодействие означает не только обмен информацией, но и взаимодействие нескольких систем для достижения определённых целей, например при распределённых вычислениях.
В описании модели ВОС содержатся определения таких важных понятий для сетевого управления, как сервис (service), интерфейс (interface) и протокол (protocol).
Сервисы, или услуги определяют функциональность соответствующего уровня
модели ВОС и могут быть предоставлены для вышестоящих уровней модели ВОС со
стороны нижестоящих уровней. В этом случае нижестоящий уровень является поставщиком услуг или служб для вышестоящего уровня [5].
Интерфейс определяет способ взаимодействия сущностей, принадлежащих
двум смежным уровням одной открытой системы. Интерфейсы определяют правила
передачи информации между уровнями и сигналы управления передачей, которые называются примитивами (primitives). В частности, в [5] говорится о примитивах запроса,
примитивах ответа и т.п. В дальнейшем, учитывая, что интерес представляют приложения модели ВОС, будут использоваться термины «запрос», «ответ», «индикация».
Протокол отражает логику взаимодействия одноранговых (одноуровневых)
сущностей при реализации ими определённого сервиса и описывает форматы данных,
которыми обмениваются сущности. Каждый протокол имеет свою версию и свой идентификатор, который передаётся при связи между уровнями. Сущности могут принадлежать различным открытым системам.
Под сущностью (entity) понимается активный элемент внутри уровня ВОС, который обладает набором функциональных возможностей, определенных для данного
уровня. В качестве физических аналогов сущности могут рассматриваться программы
управления связью межу приложениями, программы разбиения информации на кадры и
т.п. На данном уровне модели ВОС может быть несколько сущностей. Понятие сущности используется преимущественно для описания взаимосвязи открытых систем. В модели ВОС существует ещё понятие «прикладная сущность» [4], или прикладной процесс (аpplication process); это понятие относится к физическим объектам, которые удовлетворяют определению открытой системы. Прикладные процессы реализуют обработку информации в ручном режиме ввода и управления в виде выполнения компьютерных программ, с помощью дистанционного контроля (вывод аварийных сигналов АТС
на компьютер в центре технической эксплуатации). Содержательное описание прикладных процессов в интеллектуальных сетях применительно к обработке сообщений
протокола INAP содержится в [1]. Поэтому сущность в модели ВОС является абстрактным представлением функций, присущих данному прикладному процессу.
Как уже отмечалось, в модели ВОС нижестоящие уровни (уровни N) предоставляют сервисы вышестоящим уровням (уровням N+1). Сервисы обеспечиваются за счёт
функций, реализованных на уровне N, включая также функции остальных уровней N-1.
Предоставление сервисов осуществляется по запросу уровня N+1. Таким образом, сервисы запрашиваются и предоставляются между смежными уровнями; «перескочить»
через уровень N и сразу запросить услуги уровня N-1 или N-2 нельзя. Сервисы предосГлава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

26

тавляются через упомянутую выше SAP. Эти точки имеют индивидуальные адреса, которые запрашиваются уровнем N+1 при организации доступа к уровню N. Соединения
между уровнем N+1 и сервисами уровня N также имеют индивидуальные идентификаторы. Взаимодействие между уровнями обслуживается с помощью функций маршрутизации. Благодаря описанному взаимодействию осуществляется обмен между уровнями ВОС, а также между различными открытыми системами (см. рис.2.1), этот обмен
называется ассоциацией (association), или связью между подсистемами.
Связь, или ассоциация между сущностями, т.е. между уровнями открытых систем, может осуществляться как с установлением, так и без установления соединения в
режиме дуплекс, симплекс или полудуплекс. Для установления связи между уровнями
N+1 могут использоваться протоколы, сервисы и интерфейсы нижестоящих уровней,
начиная с уровня N вплоть до физической среды распространения сигнала. В случае
связи с установлением соединения имеются три фазы процесса: установление соединения, передача данных и разъединение. Установление соединения предпочтительно для
тех систем, которые находятся в постоянном информационном обмене (соединение
АТС в телефонной сети, передача данных между узлами). Режим установления соединений физически реализуется как соединение абонентов А и Б в телефонной сети с
коммутацией каналов. С другой стороны, если осуществляется обмен эпизодической
или нерегулярной информацией, то целесообразно рассматривать режим без установления соединения. Этот режим можно применять, в частности, для широковещательной рассылки данных сразу многим системам, а не только заданной системе.
Обмен информацией между уровнями ВОС осуществляется с помощью протокольного блока данных (Protocol Data Unit, PDU), который состоит из данных пользователя рис. 2.2.
(N) - PDU

Уровень N

(N-1) - PCI

Уровень N - 1

(N-1) - SDU

(N-1) - PDU

Рис. 2.2. Обмен данными между уровнями открытых систем
и управляющей информации протокола, используемой для информационного обмена.
При поступлении PDU с уровня N на уровень N-1 на нижестоящем уровне этот PDU
воспринимается как совокупность данных, чья достоверность не будет проверяться
при передачи на уровень N-1. Эта совокупность данных предлагается для обработки на
уровне N-1 как блок данных услуги (Service Data Unit, SDU), так как фактически уровень N-1 оказывает услугу уровню N по передаче данных. В свою очередь, уровень N-1
добавляет к SDU свою информацию управления протоколом (Protocol Control Information, PCI) для координации работы с уровнем N-2. В данных PCI, в частности, могут
быть указаны идентификатор и версия протокола обмена. Каждый уровень модели
ВОС добавляет к начальному информационному блоку свой блок данных PCI, который
по сути является заголовком.
Следует отметить, что семиуровневая модель OSI/RM хотя и является самой
распространенной и официально признанной, не единственная модель подобного рода.
В США применяется эталонная модель среды открытых систем, которая обозначается
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

27

как OSI/RF. Эта модель также была предложена IEEE. В отличие от семиуровневой модели ВОС данная модель предусматривает разбиение среды на три составных части:
• прикладная система;
• прикладная платформа;
• внешняя среда.
Влияние указанной модели можно обнаружить в большинстве разработок североамериканских компаний и фирм. Структура модели OSI/RF представлена на рис.2.3.

Прикладные системы
Интерфейс
прикладной
системы

Системный

Коммуникационный Информационный

Человеко-машинный

Прикладная платформа

Область
программирования

Интерфейс
пользователя

Поддержка
и
управление
данными

Обмен
данными

Графика

Сетевые
службы

Службы операционной системы
Интерфейсы
внешней
среды

Системный

Коммуникационный Информационный

Распределенная
обработка
Управление
системой
Безопасность
Интернационализация

Человеко-машинный

Внешняя среда

Рис. 2.3 Модель взаимодействия открытых систем OSI/RF
В рамках этой модели под прикладной системой понимаются прикладные
программы, рабочие данные, а также документация и средства обучения пользователей.
Прикладная платформа состоит из аппаратной платформы и программного
обеспечения, в которое входят операционная система, компиляторы, система управления базами данных (СУБД), графические системы, т.е. все средства, составляющие
операционную среду для прикладных систем.
К внешней среде относятся все системные элементы, которые являются
внешними по отношению к прикладной платформе и прикладному обеспечению. Эти
сервисные программы и прикладные системы реализуются на других (удаленных)
платформах, а также на периферийных устройствах.
Взаимодействие между прикладным обеспечением и прикладной платформой в
модели осуществляется с помощью прикладных программных интерфейсов (Application Programmer Interface, API). В области API предусматривается четыре
интерфейсных элемента для взаимодействия со следующими службами:
• системными;
• коммуникационными;
• информационными;
• службами, обеспечивающими человеко-машинный интерфейс.
Учитвая, что все перечисленные интерфейсы в той или иной степени имеются в
системах сетевого управления, можно сделать вывод о целесообразности
использования ряда элементов модели OSI/RF при анализе различных подходов к
управлению сетями электросвязи.
К достоинству модели OSI/RF следует отнести выделение внешней среды в самостоятельный элемент с определенными функциями и соответствующими интерфейГлава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

28

сами. Кроме того, модель OSI/RF содержит широкую номенклатуру служб (распределённая обработка, управление системой), которые в этой модели детально не рассматриваются. Фактически в OSI/RF сделана попытка стандартизировать не только функциональность, но и состав, структуру открытой системы на уровне прикладных задач.
Эта «технологическая» модель, в отличие от рассмотренной выше стандартной «теоретической» модели ВОС, достаточно адекватно описывает, например, системы, построенные на основе архитектуры «клиент-сервер», которые в последнее время получили
широкое распространение во многих областях.
Основное отличие между рассмотренными моделями ВОС заключается в различном делении на элементы (службы), а также в уровне абстрактности описания. Общим для всех моделей является то, что с их помощью определяются место и функции
компонент и интерфейсов, которые обеспечивают взаимодействие между программным приложением (прикладной уровень) и компонентами, которые обеспечивают те
или иные виды обслуживания прикладных программ. С учётом требований МСЭ-Т далее в качестве базовой будет рассматриваться семиуровневая модель ВОС, применяемая в стандартах ISO/ITU.
Начиная с 1995 г. появляются новые направления развития модели открытых
систем, в частности, речь идёт об эталонной модели для открытой распределённой обработки данных (Open Distributed Processing, ODP). Подробнее реализации этой модели, а также новые информационные технологии будут рассмотрены в главе 7.

2.2

Управление в модели открытых систем

2.2.1

Основные понятия и принципы управления ВОС

Основные правила управления ВОС (OSI management framework) описаны в документе ISO/IEC 7498-4: Basic Referens Model, Part 4, Management Framework (Базовая
эталонная модель. Часть 4. Структура управления). Предлагаемая модель управления
является развитием идеи общей семиуровневой модели взаимодействия открытых систем для случая, когда одна система управляет другой, т.е. имеются управляющая и
управляемая система.
В целом стандарт ISO 7498 публиковался и согласовывался по частям с 1984 г.
по 1989 г. В 1994 г. стандарт пересматривался и претерпел некоторые технические исправления и редактирование. В настоящее время представленная в документах ISO
7498 и в соответствующей Рек. МСЭ-Т X.200 модель взаимодействия открытых систем
играет роль одного из фундаментальных стандартов в области информационных технологий. В Рек. X.200 определены базовые понятия, структура, семантика, механизмы исполнения, телекоммуникационной функции, т.е. функции, обеспечивающие взаимосвязь удаленных систем посредством обмена данными, в том числе и с целью управления.
В состав стандарта ISO 7498 входят документы, указанные в табл. 2.1.

Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

Код документа
ISO – МСЭ-Т
ISO 7498
Рек. X.200
ISO 7498 Add.1
Рек. X.200
ISO 7498-2
Рек. X.800
ISO 7498-3
Рек. X.650
ISO 7498-4
Рек. X.700

Название документа
Базовая эталонная модель
(Basic Reference Model)
Передача в режиме без соединения
(Addendum 1: Connectionless-mode transition)
Часть 2: Архитектура безопасности
(Part 2: Security Architecture)
Часть 3: Наименование и адресация
(Part 3: Naming and Addressing)
Часть 4: Основные правила управления
(Part 4: Management framework)

29
Таблица 2.1
Год ввода в
действие
1984
1994
1987
1994
1989
1991
1989
1994
1989
1992

Документ ISO/IEC 7498-4, касающийся основных правил управления, состоит из
следующих основных разделов:
• термины и общие определения концепции управления;
• модель управления системами;
• информационная модель;
• функциональные области управления системами.
Документ ISO/IEC 7498-4 определяет пять основных областей, являющихся объектами функционального управления: управление неисправностями, регистрация данных управления, управление конфигурацией, производительностью и безопасностью. В
разделе 2.3 эти управляемые области обсуждаются более детально.
С учётом содержания ISO/IEC 7498-4 можно указать ряд стандартов, относящихся к управлению открытыми системами (табл. 2.2)
Таблица 2.2
Код рекомендации
Название рекомендации
ISO/ITU
ISO 9595 / X.710
Общие услуги информации управления
(Common Management Information Services, CMIS)
ISO 9596-1 / X.711
Общий протокол информации управления
(Common Management Information Protocols, CMIP)
ISO 10040
Обзор управления системами
(Systems Management Overview, SMO)
ISO 10164
Управление системами
(Systems Management)
ISO 10165
Структура информации управления
(Structure of Management Information)
ISO 10165-1 DIS
Информационная модель управления
(Management Information Model)
ISO 10165-2 DIS
Определения информации управления
(Definition of Management Information)
ISO 10165-4 DIS
Общее определение объектов управления (Guidelines for the Definition of Managed Objects)
ISO 10733 CD
Элементы информации управления, относящиеся к стандартам сетевого уровня модели ВОС
(Elements of Management Information Related to OSI Network Layer
Standards)
ISO 10737 CD
Элементы информации управления, относящиеся к стандартам
транспортного уровня модели ВОС (Elements of Management InforГлава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

Код рекомендации
ISO/ITU

30
Название рекомендации

mation Related to OSI Transport Layer Standards)
Важное значение имеет Рек. МСЭ−Т X.290 (ISO/IEC 9646), в которых определена методологическая основа тестирования соответствия разработанных вариантов сетевых протоколов стандартам модели ВОС. При таком тестировании последовательно
определяются: основные понятия, типовая структура процесса установления соответствия протоколов стандартам ВОС, абстрактные методы тестирования, средства спецификации возможных ситуаций при тестировании, структура комплексов тестов, назначение и функции лабораторий тестирования.
С точки зрения семиуровневневой модели ВОС вводятся следующие базовые
понятия управления открытыми системами [7]:
• управление приложениями (application management) – функции прикладного
уровня для управления прикладными процессами модели ВОС;
• ресурсы ВОС − вычислительные ресурсы для обработки данных и сетевые
ресурсы коммуникации, которые имеют отношение к открытым системам;
• управление системами (systems management) − функции прикладного уровня, относящиеся к управлению различными ресурсами (объектами) и их состоянием на всех уровнях модели ВОС;

управление уровнем (layer management) − функции, относящиеся к управлению уровня N согласно протокола уровня N (например, активизация некоторых функций и контроль ошибок) и некоторые функции управления системами. Управление уровня N использует коммуникационные протоколы
нижних уровней.
В модели ВОС необходимо распознавать ситуации, связанные с инициализацией, завершением и текущим контролем (мониторингом) различных действий, а также
обеспечивать координацию различных операций, например при обработке нештатных
условий функционирования системы. Перечисленные процедуры можно отнести к различным функциональным областям управления открытых систем. Операции уровня N,
осуществляемые в ходе управления, предусматривают обмен информацией между открытыми системами. Соответственно, стандартизуются только те протоколы, которые
имеют отношение к информационному обмену, поэтому протоколы модели ВОС называют коммуникационными (communications protocol). Прочие действия по управлению
в рамках модели ВОС детально не рассматриваются.
Управление системой и управление уровнями предполагают поддержку режима
работы без установления соединения между системами. В результате характеристика,
тип и содержание услуги уровня N, которая предоставляется в режиме без установления соединения, может быть передана на вышестоящий уровень до непосредственного
вызова данной услуги.
Управление приложениями затрагивает прежде всего прикладные процессы
ВОС и осуществляется на прикладном уровне. Можно указать следующие операции
управления приложениями:
• инициализация параметров прикладных процессов на физическом прототипе
открытой системы;
• инициализация, эксплуатация и завершение использования прикладных процессов;
• назначение и отмена использования ресурсов модели ВОС для прикладного
процесса;
• обнаружение и предотвращение блокировок ресурсов ВОС;
• контроль целостности системы и её данных;
• контроль безопасности системы и её данных;
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

31

• контроль восстановления системы после повреждений.
Управление системой включает в сферу своей деятельности ресурсы модели
ВОС на всех уровнях. Можно привести следующий список операций управления системой [8], который, однако, не является исчерпывающим.
1. Активизация и деактивизация управления, которая включает следующие
операции:
• активация, эксплуатация и завершение использования ресурсов модели
ВОС на всех уровнях, включая физическую среду распространения сигнала;
• загрузка программного обеспечения;
• установление, поддержка и разъединение соединений между управляемыми сущностями;
• инициализация параметров открытых систем и/или их модификация.
2. Мониторинг, или текущий контроль, который включает сообщения:
• о состоянии системы или об изменении состояния;
• о статистике состояний системы.
3. Контроль ошибок, который включает:
• обнаружение ошибок и некоторые функции диагностики ошибок;
• реконфигурацию системы и перезагрузку (рестарт) системы.
Управление уровнями открытой системы осуществляется в двух направлениях:
это активизация, во – первых, функций уровня и контроль ошибок, во−вторых, функций управления уровнем, которые являются подмножеством управления системой.
Функции управления открытыми системами допускают как централизованное,
так и децентрализованное управление. Модель ВОС напрямую не указывает степень
централизации функций управления. При реализации системы управления возможно
управление как из единого центра, так и на уровне каждого узла. Например, возможно
централизованное или децентрализованное управление телефонной нагрузкой на сетях
связи общего пользования. Кроме того, даже если данная открытая система непосредственно не взаимодействует с другими открытыми системами, то для управления можно устанавливать соединения между элементами невзаимодействующих открытых систем и осуществлять передачу сигналов управления.
2.2.2

Обмен управляющими командами в модели ВОС

С точки зрения задач сетевого управления, одна из наиболее важных проблем передача команды от управляющей системы к управляемой системе; важно получить
отклик от управляемой системы – подтверждение о получении команды, результаты
выполнения команды. Другими словами, необходимо обеспечить обмен информацией
управления между всеми участниками процесса управления с гарантированной доставкой информации управления.
В модели ВОС в зависимости от вида управления (управление системой; управление уровнем N; операция уровня N) определены три формы обмена информацией
управления.
При управлении системой происходит обмен данными, которые относятся к мониторингу, оперативному контролю и координации ресурсов открытых систем. Для
представления управляемых ресурсов в модели ВОС используют термин «управляемый
объект» (management object). В качестве управляемых ресурсов могут рассматриваться
пропускная способность каналов связи, число свободных каналов в направлении связи,
содержание маршрутных таблиц для пропуска нагрузки, административный запрет или
разрешение на пользование услугами связи и т.п. В процессе взаимодействия с управляемыми объектами осуществляется требуемое изменение ресурсов управления.
Управляемые объекты могут находиться на нескольких уровнях модели ВОС.
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

32

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

Представительный уровень
Сеансовый
уровень
Транспортный
уровень
Сетевой
уровень
Канальный
уровень
Физический
уровень

О бычные протоколы обм ена информ ацией

Прикладной
уровень

Протоколы управления
систем ой

Прикладной
уровень
Представительный уровень
Сеансовый
уровень
Транспортный
уровень
Сетевой
уровень
Канальный
уровень
Физический
уровень

Р ис. 2.4 И нформационной обмен при управлении системой

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

Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

33

Прикладной
уровень

Прикладной
уровень

Представительный уровень

Представительный уровень

Сеансовый
уровень

Сеансовый
уровень

Сетевой
уровень
Канальный
уровень
Физический
уровень

О бычные протоколы
обм ена информ ацией

Транспортный
уровень

Специальный протокол
управления N-уровня

Транспортный
уровень
Сетевой
уровень
Канальный
уровень
Физический
уровень

Р ис. 2.5 О бмен информацией при управлении N -уровнем

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

2.3

Функциональные области управления в модели ВОС

2.3.1

Функциональные области и функции управления

Стандарты управления открытыми системами обеспечивают единый подход к
решению разнообразных задач сетевого управления. В Рек. МСЭ-Т X.700, основанной
на принципах семиуровневой модели ВОС, определены следующие функциональные
области (functional areas):
• управление неисправностями (fault management);
• управление конфигурацией (configuration management);
• управление расчетами за услуги (accounting management);
• управление
рабочими
характеристиками/производительностью
(performance management);
• управление безопасностью (security management).
Перечисленные функциональные области иногда совместно обозначаются как
FCAPS (по первым буквам англоязычных обозначений). Функциональная область
управления определяет, какие ресурсы в данной системе являются управляемыми, т.е.
указывает ресурсы, которые могут целенаправленно изменяться для достижения цели
управления в процессе существования и функционирования системы.
Требования, предъявляемые со стороны пользователей и разработчиков к реализации перечисленных функциональных областей, отражаются в соответствующих спецификациях через функции управления системами (Systems Management Function,
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

34

SMF),которые реализуются за счёт сервисов или услуг управления на соответствующем
уровне модели ВОС. Все перечисленные функциональные области и соответствующие
им SMF применяются в TMN. Далее в настоящем разделе приводятся список и характеристики SMF [4,9,11], описывается каждая функциональная область и относящиеся к
ней SMF. После описания SMF даются характеристики функциональных областей
управления.
Функция управления объектом (object management function) cогласно Рек. МСЭТ X.730 включает описание базовых услуг по управлению объектом. Под объектом понимается открытая система либо её элемент, вплоть до отдельной сущность. Базовые
услуги реализуются через функции протокола общего протокола информации (Common
Management Information Protocol, CMIP), который детально обсуждается в главе 5.
Базовые функции управления объектами, определённые в Рек. МСЭ−Т Х.730,
определяют услуги, обеспечивающие манипулирование управляемыми объектами. Эти
услуги условно можно разделить на два множества:

услуги, которые относятся к общим услугам информации управления (CMIS);

услуги, которые обеспечивают дополнительные возможности по сравнению со
CMIS.
Первая категория услуг используются для создания, удаления объектов управления, т.е. выполнения действий типа «установить», «получить», «выполнить», «активизировать». С помощью услуг первой категории можно генерировать сообщения о событиях. Услуги второй категории состоят из дополнительных сервисов, связанных с
генерацией сообщений о функционировании объектов управления, в частности об изменении состояния атрибутов объектов (атрибуты подробно обсуждаются в главе 4).
Функция управления объектом не включает расширенное управление состоянием объекта, которое согласно Рек. МСЭ-Т X.731 определено функцией управления состоянием (state management function), а определяет механизм контроля за объектом,
включая мониторинг состояния и изменения состояния объекта, команды для изменения состояния объекта.
Управление состоянием объекта прежде всего определяет стандарты представления текущего состояния объекта, которое может изменяться под воздействием системы управления. Функции управления состоянием объекта обеспечивают стандарты
управления объектом на протяжении всего его жизненного цикла. Существуют три
функциональные области управления состояниями:
• определение работоспособности устройства (operability), которое определяется наличием или отсутствием ресурсов, доступных для управления. Соответственно с точки зрения работоспособности возможны два состояния объекта: разрешение (enabled) и запрет (disabled) управления ресурсами;
• использование, или загрузка устройства (usage), которое определяет, находится ли устройство под рабочей нагрузкой, а также позволяет судить о наличии свободных ресурсов. С точки зрения загрузки возможно три состояния
объекта управления: свободен (idle), активизирован/задействован (active),
используется интенсивно (busy);
• административное состояние, которое описывает возможность использования тех или иных ресурсов. Это состояние также делится на три фазы: доступ к ресурсам заблокирован (locked), ресурсы доступны (unlocked), режим
выключения или остановки (shutting down). При этом ресурсы могут быть
заблокированы, но возможность управления сохраняется. К примеру, состояние административной блокировки наступает в случае ввода неправильного пароля доступа пользователя к системе управления.
Каждое из перечисленных состояний управляемых объектов обладает различными характеристиками, которые выражаются через атрибуты; при этом атрибуты, характеризующие работоспособность и загрузку устройств, должны быть удобочитаемы
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

35

для пользователя системы управления. Атрибуты, характеризующие административное
состояние, должны быть доступны для изменения со стороны управляющей системы.
Функция управления взаимосвязями объектов (relationship management function)
согласно Рек. МСЭ-Т X.732 определяет способы взаимодействия между управляемыми
объектами. В частности, с помощью этой функции можно определить, какой объект посылает управляющие команды, а какой объект эти команды принимает и выполняет.
Функция сообщения о неисправностях (alarm reporting function) согласно Рек.
МСЭ-Т X.733 определяет механизм генерации и передачи сообщений о неисправностях. Этот механизм также включает предупреждение об обнаружении о неисправности. Предупреждение содержит характеристики, которые включают детальное описание природы аварийной ситуации, а также возможные причины её появления. Сообщение о неисправностях выдаётся с использованием CMIS и функционирует в режиме с
подтверждением или без подтверждения. Информация, которая используется для характеристики повреждений, включает в себя следующие градации аварийной ситуации:
• критическая неисправность (crtitical alarm);
• серьёзная неисправность (major alarm);
• незначительная неисправность (minor alarm);
• предупреждение о возможной неисправности (warning);
• неопределённая неисправность (indeterminate);
• устранённая неисправность (cleared).
Каждый из перечисленных видов неисправности характеризуется определёнными критериями, выполнение которых приводит к появлению определённого типа аварийного сообщения. В частности, вывод из строя не менее 50% оборудования узла
коммутации или передачи характеризуется как критическая неисправность. К таким же
последствиям может привести, например, потеря электропитания на стативах или перезапуск программного обеспечения, приводящий к потере всех текущих соединений.
Предупреждение может быть выдано в случае принудительного изменения системной
даты на узлах коммутации с программным управлением, так как данное действие приведёт к изменениям содержания полей даты и времени в файлах с данными об оказанных услугах связи. В каждом из описанных видов сообщений указываются координаты
модулей и устройств, в которых обнаружены повреждения, а также возможные причины выдачи аварийного сообщения, например потеря синхронизации.
Среди причин появления аварий можно выделить следующие:
• ошибка интерфейсного модуля (линейного комплекта);
• ошибка прикладного программного обеспечения;
• ошибка процесса установления соединения;
• ошибка протокола сигнализации;
• перегрузка;
• повреждение данных системы;
• потеря синхронизации;
• запуск недопустимой версии программного обеспечения;
• ошибка внешних систем;
• недопустимая вибрация (например, при землетрясении);
• пожар;
• перегрев или переохлаждение оборудования и т.д.
Функция управления событиями (event management function) согласно Рек.
МСЭ-Т X.734 обеспечивает механизм управления распределением сообщений о происходящих сетевых событиях, например, сообщений об аварийных ситуациях, о ликвидации аварии, извещений о запуске новой системы и т.п. Все без исключения сообщения могут поступать к оператору системы управления, а сообщения о серьёзных и критических неисправностях - на рабочее место руководителя центра управления.
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

36

Управление событиями можно рассматривать как один из ключевых элементов
систем управления по стандартам ВОС. Управление событиями контролирует распределение сообщений о произошедших в системе событиях по всей системе управления.
В Рек. МСЭ-Т X.734 определено несколько способов распределения сообщений о событиях. В основе схемы распределения сообщений о событиях находятся дискриминаторы пересылки сообщений (Event-Forwarding Discriminators, EFD). Эти дискриминаторы представляют собой объекты, которые могут использоваться для определения интервала (кванта) времени для передачи сообщения, режима передачи (с подтверждением или без подтверждения получения сообщения), а также получателей сообщений о
событиях в системе. Дискриминаторы могут использоваться для подавления вывода на
экран оператора системы управления информации о второстепенных неисправностях.
Эти сведения могут направляться напрямую в журнальный файл с данными о повреждениях (архив повреждений), т.е. в log-файлу (файл регистрации).
Основные технологии передачи сообщений о событиях включают сценарии, с
помощью которых система управления осуществляет контроль параметров, и время использования EFD на управляемых объектах, где поддерживается CMIP.
Функция управления журналированием, или регистрацией (log control function)
согласно Рек. МСЭ-Т X.735 обеспечивает запись информации об управлении в отдельный файл. Это могут быть записи в текстовом формате, например заголовки и содержание аварийных сообщений, а также запись управляющих команд, которые были введены оператором.
Управление журналированием определяет способы, которыми в системе управления поддерживается фиксация сведений обо всех событиях в системе. Услуги по
журналированию в какой-то степени аналогичны услугам по управлению событиями.
Управление журналированием подразумевает наличие механизма сохранения данных о
событиях в системе. К примеру, это означает формирование в системе управления упомянутого выше log-файла, в котором фиксируется информация о неисправностях, данные о происшедших событиях, результаты тестов отдельных модулей и общесистемных тестов, команды, поступившие от операторов. Перечисленные сведения фиксируются в log-файлах в виде текстовых сообщений или с помощью кодов сообщений.
Управление журналированием предусматривает наличие механизма изменения
критериев формирования log-файла, а также средства восстановления и удаления регистрационных записей.
Сообщение о нарушениях безопасности (security alarm reporting) согласно Рек.
МСЭ-Т X.736 определяет услуги по перенаправлению и отбору сообщений, связанных
с уведомлениями о критических режимах нарушения безопасности данных системы
управления. Указанные критические события в первую очередь выражаются с помощью аварийных сигналов безопасности (security alarms). Аварийные сигналы оповещают систему управления о потенциальных нарушениях в системе безопасности и включают сигналы об общем или эксплуатационном нарушении безопасности (например,
запрещённые операции с программным обеспечением), физическом нарушении безопасности (несанкционированном проникновении в помещение АТС, физической порче
компьютеров или их элементов). Кроме того, функция генерации аварийных сигналов
безопасности включает идентификацию возможных причин нарушений безопасности.
Следует отметить, что вышесказанное относится прежде всего к механизму генерации
сообщений о наличии проблем с безопасностью. Техника определения и фильтрации
(отбора для обработки) аварийных сигналов безопасности рассматривается отдельно
каждым разработчиком.
Тестовые (диагностические) и конфиденциальные классы объектов управления
(confidence and diagnostic test classes) согласно Рек. МСЭ-Т X.737 определяют услуги и
объекты, которые могут использоваться при управлении тестами системы и генерации
сообщений о результатах тестов.
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

37

Функция суммирования результатов (summarization function) согласно Рек.
МСЭ-Т X.738 определяет структуру, правила генерации, содержание, порядок выдачи
отчётов с обобщённой информацией о системе.
Функция мониторинга загрузки (workload monitoring function) согласно Рек.
МСЭ-Т X.739 определяет услуги по управлению и контролю загрузки системы.
Как уже отмечалось выше, управление взаимосвязями объектов определяет способы, которыми объекты воздействуют один на другой. Это относится, в первую очередь, к взаимодействию системы управления и управляемого объекта. Согласно Рек.
МСЭ-Т X.732 существуют несколько стандартных способов взаимодействия объектов,
которые подразделяются на взаимодействия:
• для оказании услуг (service);
• одноуровневых приложений (peer−to−peer);
• при нейтрализации неисправности (fallback);
• при дублировании или резервировании (backup);
• при группировке объектов (group).
Например, взаимодействие одноуровневых приложений может относится к двум
объектам, которые достаточно регулярно обмениваются информацией и находятся на
одном и том же уровне N, но в различных открытых системах. В случае, когда появляется новый управляемый объект, который должен взаимодействовать с системой
управления, перечисленные стандартные способы взаимодействия используются для
обеспечения перекрёстных ссылок на уже существующие управляемые объекты.
Общее требование ко всем функциональным областям управления состоит в
том, что вид управления определяется причиной происходящих на сети событий, т.е.
управление инициируется посредством сообщений о событиях на сети. Другими словами, управление не происходит самопроизвольно, переход от одного процесса или
процедуры управления к другой всегда обусловлен воздействием какого-то внутреннего или внешнего события. Под внешним событием понимается, например, потеря
электропитания, пожар или затопление помещения. Под внутренним событием понимается, к примеру, истечение предельного времени выполнения определенного задания или теста, сбой программного обеспечения, выход из строя функционального модуля.
2.3.2

Характеристика функциональных областей

Управление неисправностями (fault management) характеризуется прежде всего функцией генерации специфических сообщений о неисправностях – так называемых тревог (alarms). При этом осуществляется регистрация источника сообщений об
ошибке и начинается тестирование сетевых ресурсов с тем, чтобы идентифицировать
и контролировать неисправности. При управлении неисправностями необходимо
предпринимать действия по наблюдению за неисправностями (анализ, фильтрация и
корреляция сообщений о неисправностях), выполнять тестирование неисправного ресурса, обеспечивать локализацию неисправности, а также исправлять неисправности.
Основное требование к управлению неисправностями – это наличие операций
(процедур) управления, инициируемых определенными сетевыми событиями. Кроме
того, необходимо четко определить основные и второстепенные тревоги и установить
правила тестирования. Соответствующие SMF – это сообщений о событиях (event
reporting) согласно Рек. МСЭ-Т X.734, журналирование сообщений (logging) согласно
Рек. МСЭ-Т X.735, сообщение о неисправности (тревоге) согласно Рек. МСЭ-Т X.733
и тестирование согласно Рек. МСЭ-Т X.737, X.745.
Управление конфигурацией (сonfiguration management) обеспечивает инициализацию (запуск), установку и обеспечение функционирования оборудования связи. Это
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

38

позволяет осуществлять в едином комплексе работы по пуско-наладке оборудования и
передачу информацию о состоянии оборудования по запросу администратора сети. Появляется техническая возможность обеспечивать средства технического учета оборудования и поддерживать уведомления об изменениях конфигурации оборудования через
соответствующие сообщения.
Основные требования к управлению конфигурацией: наличие операций (действий) над объектами управления, которые зависят от определенных событий; контроль
изменений конфигурации, контроль первичного состояния ресурсов сети; представление связей и взаимоотношений между объектами управления в форме, понятной для
разработчика системы управления и пользователя; возможность планирования сети;
управление временем; распределение программного обеспечения и наличие средств
восстановления системы. Соответствующие SMF - это сообщения о событиях согласно Рек. МСЭ-Т X.734, журналирование, или регистрация событий (logging) согласно
Рек. МСЭ-Т X.735, управление состоянием согласно Рек. МСЭ-Т X.731, управление
взаимосвязями объектов согласно Рек. МСЭ-Т X.732, планирование сети согласно Рек.
МСЭ-Т X.746, управление временем (time management) согласно Рек. МСЭ-Т X.743,
распределение программного обеспечения (software distribution) согласно Рек. МСЭ-Т
X.744 и управление совместным использованием знаний (shared management
knowledge) согласно Рек. МСЭ-Т X.750.
Управление расчетами (accounting management) за услуги связи - это совокупность процедур учета информации о количестве оказанных услуг связи и обработки
зафиксированных данных в целях подготовки счетов с начислениями за услуги связи.
Применение управления расчетами должно дать возможность оператору установить
обоснованную плату за использование сетей и оборудования связи, определить себестоимость многочисленных услуг связи.
Ключевые требования к управлению расчетами - наличие операций (действий
над объектами), зависящих от событий, в особенности регистрация услуг и основные
правила регистрации (фиксации) использования услуг (usage metering) связи или сетевого ресурса. Соответствующие SMF – сообщения о событиях согласно Рек. МСЭ-Т
X.734, регистрация событий согласно Рек. МСЭ-Т X.735 и измерения использования
ресурсов для начислений (accounting metering) согласно Рек. МСЭ-Т X.742.
Управление рабочими характеристиками и производительностью (performance
management) сети предполагает наличие и доступность информации управления с целью определения технического состояния сети и загрузки системы связи при естественных и искусственных, т.е. смоделированных условиях. Управление рабочими характеристиками сети поддерживает совокупную информацию об эффективности работы сети, которая поступает периодически, обеспечивая тем самым статистику работы сети, и позволяя планировать различные управляющие воздействия.
Для управления характеристиками сети необходим доступ к большому количеству сетевой информации. При этом особенно важна проблема обеспечения степени
воздействия на управляемую сеть. Как правило, желательно, чтобы каждое отдельно
взятое воздействие было минимальным. Ключевые требования для данного вида
управления – способность преобразования первичной информации о сетевой ситуации в формальные показатели (с учётом пороговых значений этих показателей) в соответствующие периоды времени. К такого рода задачам относится, например, задача
преобразования сведений о количестве и продолжительности поступивших вызовов в
данные о нагрузке канала связи и последующего вывода о наличии перегрузки.
Даже из такого простейшего примера следует, что при управлении производительностью необходима процедура периодического агрегирования (обобщения) информации об эффективности работы сети для выявления тенденций развития сетевой
ситуации и планирования пропускной способности. Соответственно, необходимы
средства планирования для регулярного сбора информации о работе сети, а также
Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

39

возможность определения времени получения отклика о состоянии объектов управления на сети.
Для данной функциональной области существуют следующие SMF: сообщения
о событиях согласно Рек. МСЭ-Т X.734, регистрация сообщений согласно Рек. МСЭ-Т
X.735, метрический контроль (metric monitoring) согласно Рек. МСЭ-Т X.739, объединение информации (summarisation) согласно Рек. МСЭ-Т X.738, планирование с помощью составления расписания (scheduling) согласно Рек. МСЭ-Т X.746 и контроль
времени ответа на запрос (response time monitoring) согласно Рек. МСЭ-Т X.748.
Управление безопасностью (security management) затрагивает два аспекта защиты систем:
• управление собственно безопасностью (management of security) - способность контроля и управления средствами защиты и своевременного
сообщения об угрозах безопасности или нарушениях безопасности сетей и средств связи;
• безопасность управления (security of management) - возможность опознавания пользователей системы управления и соответствующих прикладных программ, что гарантирует конфиденциальность и целостность
обмена информацией управления и предотвращает несанкционированный доступ к информации управления. Услуги установления подлинности, обеспечения целостности данных и конфиденциальности являются
общими для всех прикладных программ ВОС и затрагивают все процедуры управления согласно Рек. МСЭ-Т X.800.
Ключевые требования при управлении безопасностью согласно модели ВОС –
это поддержка аварийных сообщений о безопасности, средства для проведения аудита
безопасности и средства управления доступом. Соответствующие SMF: сообщения о
событии согласно Рек. МСЭ-Т X.734, регистрация согласно Рек. МСЭ-Т X.735, аварийные сообщения о безопасности Рек. МСЭ-Т X.736, аудит выполняемого процесса
безопасности (security audit trail) согласно Рек. МСЭ-Т X.737, управление доступом
согласно Рек. МСЭ-Т X.741.
Итак, перечисленные функции управления позволяют реализовать задачи
управления в каждой из вышеперечисленных функциональных областей. Результаты,
полученные в модели ВОС, в полной мере используются в концепции TMN, которая
рассматривается в следующей главе. Следует особо отметить, что рассмотренная модель управления ВОС рассматривает телекоммуникационное и вычислительное оборудование в общем, безотносительно к конкретному типу или к конкретной архитектуре. Это свойство модели ВОС позволяет применять её для самых разнообразных
устройств.

Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

40

Список источников к главе 2
1.

Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Интеллектуальные сети. − М.: Радио и
связь, 2000. – 500 c.

2.

Лазарев В.Г. Интеллектуальные цифровые сети: Справочник/Под. Ред. академика
Н.А. Кузнецова. − М.: Финансы и статистика, 1996 г.− 224 с.

3.

Построение систем управления сетями связи операторов ВСС РФ. Руководящий
документ. – М.: Минсвязи России, 2001.

4.

Сборник «Открытые системы»// Материалы к межотраслевой программе «Развитие
и применение открытых систем». − М.: 1995 г.

5.

Халсалл Ф. Передача данных, сети компьютеров и взаимосвязь открытых систем:
Пер. с англ. − М.: Радио и связь, 1995 г. − 408 с.

6.

ITU−T Recommendation X.200. Information technology. Open systems interconnection.
Basic reference model: The basic model. − 1994.

7.

ITU−T Recommendation X.700. Management framework for open system interconnection (OSI) for CCITT applications. − 1992.

8.

ITU−T Recommendation X.701. Information technology. Open systems interconnection.
Systems Management overview. − 1992.

9.

Cekro Z.. Telecommunications Management Network (TMN) and OSI Systems Management. Standards and Emerging Trends/ Vrije Universiteit Brussel. Universite libre de
Bruxelles. Faculte de sciences. Режим доступа :
[http://citeseer.nj.nec.com/cache/papers2/cs/5601/http:zSzzSzwww.mice.iihe.ac.bezSzint
ernal-reportzSzstc-98-08.pdf/cekro98telecommunication.pdf 29.08.01].

10. Pavlou G. Telecommunications Management Network: a Novel Approach Towards its
Architecture and Realisation Through Object-Oriented Software Platforms/ PhD thesis.
Режим доступа : [ftp://cs.ucl.ac.uk/osimis/papers/phd-gp/02-contents.pdf 14.02.2001]
11. Tessier Jean Un cadre d’application pour interfaces de gestion OSI. Maître ès sciences
(M.Sc.) en informatique/ Université de Montréal, Département d’informatique et de recherche opérationnelle. Режим доступа
[http://www.iro.umontreal.ca/~labgelo/Publications/Theses/msc-tessier.pdf 19.05.01]

Глава 2 версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

41

3. СЕТЕВОЕ УПРАВЛЕНИЕ ПО СТАНДАРТАМ TMN
3.1

Основные положения концепции TMN

3.1.1

Состав и назначение основных элементов TMN

Термин Telecommunication Management Network (TMN) введен МСЭ-Т с 1992
г. и означает «Сеть управления электросвязью». Общие положения концепции TMN
определены в Рек. МСЭ-Т M.3010. Концепция TMN основана на базовых принципах
управления открытыми системами. Согласно Рек. МСЭ−Т M.3010, TMN является
самостоятельной сетью, которая соединена с сетью электросвязи. Архитектура и
принципы построения TMN обеспечивают реализацию задач по управлению,
оперативному контролю и эксплуатации разнородного телекоммуникационного
оборудования и систем электросвязи, которые изготовлены различными
фирмами−производителями (рис. 3.1). TMN предназначена для управления услугами
сетей связи, для эксплуатации и технического обслуживания оборудования, для
оперативно−технического контроля и администрирования сетевыми устройствами в
целях обеспечения нормативного качества оказания услуг связи [1, 3, 6 – 8].
TM N

О перационная
система

Операционная Операционная
система
система

Сеть передачи данных
К другим
системам
TM N

Абонент А

Рабочая
станция
TM N
S
D
H
Система
корммутации

Система
передачи

S
D
H
Система
передачи

Система
корммутации

Абонент Б

Сеть электросвязи

Рис. 3.1 TMN и сеть электросвязи (согласно Рек. МСЭ-Т М.3010)
Объектами управления TMN являются телекоммуникационные ресурсы.
Телекоммуникационные ресурсы управления физически представляют собой
реальное оборудование связи – стативы, функциональные блоки, модули, на
определенные свойства которых можно осуществлять целенаправленное
управляющее воздействие. Например, можно запрещать организацию обходных
направлений связи через определённый узел связи или повышать уровень
допустимых потерь в направлении связи (см. также раздел 3.2).

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

42

TMN предоставляет оператору связи услуги по управлению сетями
электросвязи (management service). Услуги управления определяются как
компоненты, предлагаемые TMN для удовлетворения потребностей оператора в
сетевом управлении. Самая элементарная из этих компонентов, например генерация
сообщения о неисправности, определяется как функция управления (management
function). TMN предоставляет оператору связи широкий набор функций управления
телекоммуникационными сетями и услугами, обеспечивая обмен информацией в
процессе управления. Обмен информацией предусматривает прежде всего выдачу
команд управления, получение подтверждения получения команд, их выполнение и
передачу в систему управления результатов выполнения команд.
Обмен командами управления и иной информацией между TMN и
оборудованием связи осуществляется через опорные точки (reference points), которые
реализуются в виде стандартизованных или нестандартизованных интерфейсов TMN.
Для передачи сигналов и команд управления TMN соединяется с оборудованием
систем и средств электросвязи при помощи сети передачи данных (Data
Communication Network, DCN). DCN реализует транспортные уровни TMN согласно
модели ВОС.
Функции прикладного уровня TMN реализуются с помощью одной или
нескольких операционных систем (Operations Systems, OS).

База
данных
сетевого
управления

Приложение
управления
Приложение
управления

Модель сети

Операционная или управляющая система (OS) TMN

Рис. 3.2 Операционная система в TMN
В первую очередь, операционные системы (рис. 3.2) обеспечивают обработку
данных, поступающих от управляемой сети электросвязи, в целях мониторинга и
контроля функционирования телекоммуникационного оборудования, а также для
обеспечения работы собственно TMN; поддерживают информационную модель сети
электросвязи, которая представляет собой описание физических объектов
электросвязи с использованием принятой информационной технологии и
специальных программных средств, например систем управления базами данных
(СУБД); обеспечивают работу прикладных программных средств управления
(приложение управления), которые, собственно, и реализует большинство услуг и
функций управления системами. Функции управления могут выполняться
непосредственно человеком-оператором или в автоматическом режиме. Кроме того,
OS обеспечивает поддержку терминалов пользователя, форматирование данных [7].
Некоторые функции управления могут выполняться несколькими
операционными системами. В этом случае DCN используется для обмена
информацией между различными управляющими системами, а также для соединения
между рабочими станциями (Work Stations,WS) и операционными системами, что
позволяет
операторам и администраторам получать и интерпретировать

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

43

информацию управления.
Рабочие станции имеют графические человеко-машинные интерфейсы
согласно Рек. МСЭ−Т Z.300; детальное определение такого интерфейса находится
вне рамок рекомендаций МСЭ−Т по TMN. Рабочая станция поддерживает язык
общения «человек-машина» и обладает
возможностями обработки данных,
средствами ручного и автоматического ввода-вывода информации. Вместо WS
может использоваться терминал управления.
Кроме того, на основе DCN данная TMN может взаимодействовать с другими
аналогичными TMN. Это взаимодействие по сути является взаимодействием
различных операционных систем.
Минимальные возможности TMN обеспечивают единичное соединение между
управляющей системой, рабочей станцией и отдельным устройством электросвязи. В
максимальной конфигурации TMN представляет собой технически сложную сеть,
которая объединяет в единый комплекс управления значительное число различных
систем и средств электросвязи, используя при этом несколько типов управляющих
систем, с учётом территориальной удаленности объектов управления друг от друга.
При этом в TMN учитывается, что сеть электросвязи состоит из многих типов
аналогового и цифрового оборудования, в частности, систем передачи SDH, PDH,
электронных АТС, сигнальных пунктов системы общеканальной сигнализации
(ОКС) №7, оборудования для оказания телематических услуг, серверов доступа в
Интернет, маршрутизаторов и коммутаторов сетей передачи данных. По стандартам
TMN такое оборудование обычно называется элементом сети, или сетевым элементом
(Network Element, NE). При необходимости описание элемента сети в TMN можно
детализировать до уровня отдельной стойки, статива, функционального блока,
модуля. Элементы сети предоставляют клиентам и абонентам услуги электросвязи
благодаря использованию телекоммуникационных технологий, а также
поддерживают обмен с OS. При этом элемент сети может быть централизованным
или распределённым, в том числе географически [7,15]. В последнем случае имеется
в виду, например, АТС и её выносы, территориально протяженная система передачи
и т.п.
3.1.2

Функции и уровни TMN

С учетом характеристик управления открытыми системами TMN
функционально должна обеспечивать:
• обмен информацией управления между сетями электросвязи и сетью TMN;
• преобразование информации управления для различных систем связи в
единый формат с целью обеспечения совместимости и согласованности
данных в TMN;
• перенос информации управления между различными компонентами в TMN;
• анализ и соответствующую реакцию на информацию управления;
• преобразование информации управления в форму, которая понятна
пользователю системы управления – оператору или администратору. В
результате повышается качество услуг управления и обеспечивается
дружественное взаимодействие с пользователями посредством общепринятых
стандартов графического отображения информации;
• защищенный доступ к информации по управлению для пользователей TMN;
• контроль крупных и сложных объекты управления.
С точки зрения оператора связи можно сформулировать следующие цели,
Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

44

которые должны быть достигнуты при внедрении TMN:
• минимальное времени реакции системы управления на существенные сетевые
события;
• минимизация нагрузки, создаваемой системой управления; это особенно важно в
случае, когда для передачи информации управления используются ресурсы сети
электросвязи общего пользования, а не выделенные каналы связи;
• реализация процедур для изоляции мест повреждения (неисправностей) в
реальном времени, возможность дистанционного вызова и запуска процедур
восстановления повреждений;
• учёт различных схем организации сетей связи при реализации функций
управления.
При детальном рассмотрении сети электросвязи в контексте концепции TMN
можно выделить три функциональных уровня (plane) (рис. 3.3) [3]:

Уровень
менеджмента
(TMN)

Уровень
управления
оборудованием
Уровень
пользователя

Операционная
система
Рабочая
станция TM N

Сеть передачи данных

Оборудование связи

Абонент А

Абонент Б

Рис. 3.3 Уровни управления в сети TMN

Уровень пользователя (user plane). На этом уровне осуществляется оказание
пользователю услуг электросвязи, например, приём и передача речи,
пакетизированных данных, видеоизображений и т.п.

Уровень управления оборудованием (control plane) представляет собой
непосредственное управление оборудованием связи с помощью встроенного или
загружаемого программного обеспечения, которое в реальном времени
осуществляет технологическое управление процессом установления соединений
и разъединений, маршрутизацию вызовов, обмен и обработку сигнализации и
т.п. Для устаревшего электромеханического оборудования управление
осуществляется с помощью релейных схем.

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

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

45

инфраструктуры, реконфигурацию сети в случае неисправностей с тем, чтобы
позволить уровню пользователя и уровню контроля функционировать с
максимальной эффективностью.
Уровень пользователя или абонента сети электросвязи рассматривается в
TMN с точки зрения обмена данными по управлению с элементами сети NE. Обмен
осуществляется через стандартизованные интерфейсы TMN. На уровне пользователя
технически осуществляется доступ к услугам управления. На уровне управления
оборудованием реализуются функции технологического управления системами
связи, которые встроены в элементы сети на программно-аппаратном уровне и
используют общепринятые протоколы сигнализации. Здесь основной задачей
является предоставление услуг связи и процессов установления соединения в
реальном времени, оперативное выявление повреждений и генерация первичной
информации управления.
Уровень менеджмента содержит функции, реализованные с помощью
прикладного программного обеспечения, что обеспечивает вмешательство в работу
технологического управления сетей и систем электросвязи. На этом уровне
непосредственно не затрагивается процесс обслуживания поступающих вызовов.
Представленное деление на уровни в настоящее время не включается в
официальные рекомендации МСЭ−Т, но позволяет более четко определить роль и
место TMN в телекоммуникациях. TMN непосредственно не предоставляет
универсальные и новые услуги связи, однако поддерживает услуги управления [4],
которые необходимы для контроля качества предоставления универсальных услуг
связи и обеспечения безаварийного функционирования сетей связи. TMN
поддерживает также услуги управления, которые используются конечными
пользователями, например, заказ услуги, учет объема пользования и расчет за услугу
(accounting), управление составом или профилем услуг пользователя (service profile
customisation). Перечисленные возможности объединяются под общим названием
«Администрирование услуг пользователем».
TMN осуществляет мониторинг всей сети электросвязи (а не только
локальных участков, как это делается на уровне управления оборудованием),
вырабатывает управляющие решения, исходя из реальных сетевых условий и
сопутствующей информации. При этом могут использоваться элементы экспертных
систем и баз знаний о возможном развитии сетевых событий. Воздействие на сеть
электросвязи осуществляется по принципу «обратной связи» с целью корректировки
управляющих воздействий с учетом последствий управления. Обратная связь
позволяет сети электросвязи функционировать «разумно» в той мере, насколько это
возможно, без наделения элементов сети дополнительными функциями управления.
В сущности, «интеллект» сетевого управления функционирует «снаружи» сети
электросвязи, что расширяет возможность централизованного предоставления услуги
управления для интеллектуальных сетей, сетей подвижной радиосвязи, сетей доступа
и т.п. В заключение необходимо добавить, что, поскольку TMN «не вмешивается» в
управление услугами связи в реальном времени, она менее требовательна к
требованиям работы в реальном времени.
С учётом сложности и многообразия задач, решаемых TMN, существуют
несколько способов описания ее свойств. Каждый способ описания соответствует
ряду свойств сети. В терминах TMN в этом случае говорится об архитектуре сети.
Здесь под архитектурой понимается совокупное обозначение состава и структуры
TMN, взаимное расположение и способы взаимодействия компонентов TMN между
собой и с внешней средой. Рек. МСЭ−Т M.3010 определяет общие понятия

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

46

концепции управления TMN и представляет несколько видов архитектуры
управления с позиции различных уровней ее описания:
• функциональная архитектура TMN, которая описывает ряд функций
управления;
• физическая архитектура TMN, которая определяет, как и какими средствами
функции управления могут быть реализованы на вычислительном и ином
оборудовании;
• информационная архитектура TMN, которая описывает понятия TMN на
основе стандартов управления ВОС в рамках объектно-ориентированного
подхода;
• логическая многоуровневая архитектура TMN (Logical Layered Architecture,
LLA), которая показывает, как управление сетью может быть структурировано в
соответствии с различными потребностями администрации связи.
Подробнее каждый из рассмотренных уровней рассматривается в разделе 3.2.
3.1.3

Структура и развитие рекомендаций МСЭ-Т в части TMN

Основные положения концепции TMN и перечисленные виды архитектуры
стали результатом длительного исследовательского процесса и работ по
стандартизации. Исследования по TMN были начаты в 1985 г. IV исследовательской
группой МККТТ (ныне – МСЭ-Т). Первая рекомендация TMN имела код M.30 и
была издана в 1988 г. как часть «Синей книги». В 1992 г. появилась полностью
пересмотренная версия данной рекомендации, и её номер был изменен на M.3010.
Эта версия вновь претерпела изменения в 1996−2000 гг.
По сравнению с версией M.30 от 1988 г., в версии M.3010 в 1992 г. удалены
разделы по планированию и проектированию и раздел «Функции, связанные с
TMN». В версии 1992 г. добавлен также ряд новых разделов, в первую очередь
«Информационная архитектура TMN». Наиболее важные изменения в версии 1996 г.
касаются логической многоуровневой архитектуры TMN. Однако для второй
половины 1990-х годов были характерны новые достижения в отрасли
информационных технологий, началась практическая конвергенция сетей для
передачи речи и данных, развивались интеллектуальные сети, существенно
сократились сроки внедрения новых услуг электросвязи. Это привело к
необходимости пересмотра некоторых принципов TMN. В результате начиная с
февраля 2000 г., ITU-T приступил к публикации пересмотренных рекомендаций,
относящихся к концепции TMN-2000. В дальнейшем, если не будет сделано
специальных оговорок, рассматриваются положения, вошедшие в версии
рекомендаций TMN, начиная с 2000 г.
С 1988 г. также сформированы более 20 рекомендаций серии M.3xxx,
связанных с TMN. Эти рекомендации призваны совершенствовать специфические
аспекты TMN, используя при этом M.3010 как основу для углубления и доработки
положений TMN (рисунок 3.4 и приложение 1).
Большое количество рекомендаций TMN было разработано для управления
сетями ISDN (см. приложение 1). Европейский институт по стандартизации
телекоммуникаций (Europe Telecommunication Standart Institute, ETSI), в свою
очередь, разработал ряд спецификаций отдельных элементов TMN, в частности,
интерфейса Q.3 для управления сетями SDH, а также выделенными линиями связи
(см. приложение 1).

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

Обзор рекомендаций по
TMN, Рек. M.3000

Принципы TMN,
Рек. M.3010

47

Термины и определения
TMN, Рек. M.60

Методология спецификации
интерфейсов TMN,
Рек. M.3020

Базовая информационная
модель сети для TMN,
Рек. M.3100

Обзор услуг управления
TMN, Рек. M.3200

Возможности управления
TMN на интерфейсе F
Рек. M.3300
на интерфейсе X
Рек. M.3300

Каталог информации
управления TMN,
Рек. M.3180

Функции управления TMN,
Рек. M.3400

Рис. 3.4 Логические взаимосвязи между рекомендациями TMN
Архитектура сети TMN обладает рядом характеристик, отличающих ее от
основных конкурентов − SNMP-продуктов и фирменных систем управления,
основанных на частных стандартах, например, систем на основе TL/1(M), широко
используемого североамериканскими операторами, но мало распространенного в
Европе.
Наиболее значимыми из особенностей архитектуры TMN являются:
• возможность интеграции управления разнородными сетями за счет комплексной
стандартизации большого числа аспектов поведения и структуры системы
управления, а также в силу того, что стандарты TMN являются официальными
стандартами МСЭ−Т;
• высокая
степень
масштабируемости
решений
благодаря
поддержке
семиуровневой модели ВОС и специальным элементам для построения больших
распределенных систем: промежуточной сети передачи данных, средств
маршрутизации и фильтрации сообщений с управляемыми объектами, наличие
информационной базы данных, хранящей информацию об их свойствах и
местоположении и т. п.;
• защищенность управления посредством использования открытых стандартов
безопасности ISO/OSI.
В следующем
разделе
детально рассматриваются различные виды
архитектуры TMN.

3.2

Виды архитектуры TMN

3.2.1

Функциональная архитектура TMN

Функциональная архитектура TMN состоит из следующих основных компонентов:
• функциональные блоки (functional blocks) − наименьшие (элементарные) единицы
TMN, которые могут быть стандартизированы;
• функции приложений управления (Management Application Functions, MAF) Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

48

функции, которые предоставляют одну или несколько услуг управления.
Название MAF может соответствовать функциональным блокам, где они
применяются. Данные функции являются основой для формирования услуг
управления. В рамках одного функционального блока реализуется одна MAF;
• функции управления TMN (TMN Management Function, TMN MF) и набор
функций управления TMN (TMN management function sets). Функции управления
TMN обеспечивают взаимодействие между парами MAF в управляющей и
управляемой системах и группируются в набор функций управления. Набор TMN
MF является
многократно используемым компонентом, который можно
применять для различных услуг управления, не зависит от протоколов,
применяемых в коммуникационной модели управления;
• опорные точки (reference point) – описание требований к интерфейсам TMN.
Опорные точки не определяют протокол информационного обмена, но отражают
суть взаимодействия между функциональными блоками, позволяют определить
все возможные функции, которые данный функциональный блок запрашивает у
других блоков, и служат своего рода «разделителями» функциональных блоков.
Итак, функциональные блоки по сути являются абстрактным описанием
функциональных возможностей TMN, например, функций:
• сети передачи данных;
• рабочей станции;
• интерфейса «человек-машина»;
• базы данных управления;
• безопасности сети TMN;
• обмена сообщениями.
В функциональной архитектуре TMN определено четыре различных типа
функциональных блоков. Нет необходимости, чтобы все типы присутствовали в
каждой возможной конфигурации TMN. С другой стороны, большинство реализаций
TMN поддерживают несколько функциональных блоков одного и того же типа.

TM N
TF

OSF

TF

W SF

NEF

Рис. 3.5 Функциональные блоки TMN

На рисунке 3.5. показаны четыре типов функциональных блоков:
управляющей системы (Operations Systems Function block, OSF);

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

49



элемента сети (Network Element Function block, NEF);
рабочей станции (Workstation Function block, WSF);
преобразования (Transformation Function block, TF).
Два типа блоков (OSF и TF) полностью находятся внутри области,
помеченной как «TMN». Это указывает на то, что эти функциональные блоки
полностью определены в соответствии c рекомендациями TMN. Оставшиеся три
блока (WSF, NEF и TF) показаны на граничной линии. Это указывает на то, что
только часть функциональных блоков определены в рекомендациях TMN.
Функциональная архитектура TMN вводит понятие опорных точек (reference point),
чтобы обозначить границы взаимодействующих функциональных блоков. Три класса
опорных точек (q, f и x) полностью описаны в рекомендациях TMN; другие классы (g
и m) располагаются вне систем TMN и описываются рекомендациями МСЭ−Т лишь

g

g
W SF

W SF

TM N

f

f

TM N

q

x

f

q

OSF

OSF

q
OSF

q

q

q

q

q
NEF

NEF

TF

частично (рис. 3.6).
Рис. 3.6 Опорные точки и функциональные блоки TMN
Функциональный блок элемента сети, NEF. Как говорилось выше, в
терминологии TMN управляемое оборудование, т.е. физические компоненты сетей и
систем связи, обозначаются как элементы сети NE. Таким образом, NEF описывает
функции оборудования электросвязи, которые доступны для управления со стороны
TMN. Эти функции не являются частью TMN, что обозначено на рис. 3.5 Кроме того,
NEF поддерживает обмен информацией с TMN для обеспечения передачи
управляющих команд и информации управления. Именно эта часть NEF, которая
доступна TMN, изображена на рис. 3.5 внутри границ TMN.
Функциональный блок управляющей системы, OSF. Функции
управляющей системы инициализируют операции управления и получают
сообщения/уведомления о их выполнении. OSF устанавливает связь и
взаимодействует с NEF через опорную точку q (версия Рек. МСЭ−Т M.3010,
действующая с 02.2000 г.). Следует отметить, что в начальной версии рекомендации

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

50

M.30 в 1988 г. было определено три различных опорных точки : q1, q2 и q3, а в версии
1997 г. присутствовали только опорные точки q3 и qx. Этому имеется следующее
объяснение.
Опорная точка q3 использовалась каждый раз, когда требовалось передать
информацию управления на прикладном уровне модели ВОС. Опорные точки q1, q2
предназначались для случаев, когда информацию управления нужно передавать
через более низкие уровни модели ВОС (например, через канальный и сетевой
уровени). По прошествии некоторого времени оказалось, что невозможно различить
q1 и q2. Эти две опорные точки были заменены общей точкой qx , а в 2000 г. все
указанные опорные точки объединены под общим обозначением q.
Рисунок 3.7 показывает отношение между OSF, NEF и q . Услуги,
предоставляемые в опорной точке q, в основном относятся к услугам CMIP.
Граница между
функциональными
блоками

OSF

NEF

Опорная точка q

Рис. 3.7 Взаимосвязь между OSF, NEF и опорной точкой q
Как видно из рис. 3.7, на отдельно взятой сети TMN (эксплуатируемой одной
администрацией связи) обмен между несколькими OSF осуществляется через
опорную точку q. Связь между OSF в различных TMN (эксплуатируемых
различными администрациями связи) осуществляется на основе опорной точки x.
Рис. 3.7 показывает реализацию функциональной модели рис. 1.9.
Функциональный блок рабочей станции, WSF позволяет представлять
информацию управления для пользователя в наиболее доступной и ясной форме.
WSF включает поддержку интерфейса с пользователем через опорную точку g. Этот
аспект WSF не являются частью стандартов TMN, поэтому на рисунке 3.5 WSF
расположена на краю оболочки TMN , а опорная точка g на рис. 3.6 – вне рамок
TMN.
Функциональный блок преобразования, TF используется для организации
связи между двумя сущностями, которые имеют несовместимый механизм
информационного обмена. Несовместимыми могут оказаться информационные
модели, протоколы обмена или оба этих элемента. TF может использоваться как для
связи функциональных блоков внутри сети TMN, так и для организации
взаимодействия с внешними системами. В частности, на границе TMN TF
обеспечивает взаимодействие с окружением, которое не соответствует стандартам
TMN, и преобразует информацию на участке от опорных точек q (которые являются
стандартными опорными точками TMN) и опорными точками m. Так как опорная
точка m не является целиком стандартной с точки зрения TMN, часть TF показана на
краю оболочки TMN. Кроме того, TF осуществляет хранение, и фильтрацию и
преобразование информации управления из некоторой локальной или частной
формы в стандартизированную форму.
Функциональный блок TF выполняет функции Q-адаптера (Q Adaptor

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

51

Function, QAF), которая присутствовала в прежних версиях рекомендаций TMN (см.
например, версию Рек. МСЭ-Т M.3010, действовавшую с 05.1996 г.). Так же, как TF,
функция QAF использовалась, чтобы соединить с TMN объекты, которые не
поддерживают опорные точки стыка TMN. Одновременно на TF возложена
реализации ранее существовавшей функции медиации (Mediation Functions, MF),
которая использовалась для организации соединения и взаимодействия между
одиночными или множественными NEF/QAF и OSF.
Взаимосвязи между функциональными блоками и соответствующими
опорными точками приведены в табл. 3.1.
Таблица 3.1. (Рек. МСЭ-Т M.3010)
NEF
OSF
TF
WSF
Не TMN
q
q
NEF
q
q, x1
q
f
OSF
q
q
q
f
m
TF
f
f
g
WSF
m
g
Не TMN
Примечания.
1
x интерфейс применяется, когда OSF находятся в разных функциональных блоках.
Опорная точка g находится между WSF и персоналом, управляющим сетью.

Функциональный блок наверху столбца может обмениваться информацией
управления с функциональным блоком в левом столбце через опорную точку,
которая указана на пересечении столбца и строки. В случае, если пересечение пусто,
функциональные блоки не могут непосредственно обмениваться информацией
управления друг с другом.
Кроме перечисленных элементов, описание функциональной архитектуры
TMN до 2000 г. включало некоторые дополнительные функции, в частности
функцию передачи данных TMN (Data Communication Function, DCF). Несмотря на
то, что описание указанных функций исключено из текущей версии рекомендации
M.3010, на практике они действуют.
Функция передачи данных, реализованная сейчас в DCN, обеспечивает с 1 по
3 уровни (транспортные уровни) TMN согласно семиуровневой модели ВОС. То же
можно сказать о функции передачи сообщений (Message Communication Function,
MCF), которая сейчас не выделяется, но присутствует во всех функциональных
блоках, которым требуются услуги протоколов нижнего уровня модели ВОС для
осуществления обмена информацией управления. MCF реализована с
использованием стека протоколов, которые позволяют соединить функциональные
блоки с DCN.
3.2.2. Физическая архитектура TMN

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

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

52

оборудования. Физическая архитектура TMN менее абстрактна, чем функциональная
архитектура, и показывает, как функциональные блоки могут реализованы с
помощью физических блоков (phisical blocks).
Физическим блокам соответствуют оборудование связи, ЭВМ, системное или
прикладное программное обеспечение. Опорные точки реализуются с помощью
интерфейсов (interfaces). Физическая архитектура определяет, как функциональные
блоки и опорные точки могут быть реализованы с помощью программно-аппаратных
средств (рис. 3.8):

Функциональная
архитектура TMN

Физическая
архитектура TMN

Ф ункциональные
блоки

Ф изические
блоки

+

+

Опорные
точки

Ф изические
блоки

Рис. 3.8 Взаимосвязь между различными архитектурами TMN





Физическая архитектура TMN состоит из следующих физических блоков:
Элемент сети (NE);
устройство медиации (Mediation Device, MD);
Q-адаптер (QA);
операционная система (OS);
рабочая станция (WS);
сеть передачи данных (DCN).
Физическая архитектура TMN представлена на рис. 3.9.

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

53

TMN
Операционная система
OS

X/F/Q
К другой OS

X

G

F
Сеть передачи данных DCN

Q
Q

Q

Q

Рабочая
станция W S

Q-медиатор

Q-адаптер

Элемент сети NE
со стандартным
соединением с TM N

Элемент сети NE
с нестандратным
соединеним с TM N

Интерф ейс

Рис. 3.9. Физическая архитектура TMN
Физические блоки являются реализацией одноименных функциональных
блоков. Например, блок «Элемент сети» выполняет функции оборудования связи.
Функции трансформации в данном случае разделяются на две составляющие:
функции адаптации, которую реализуют устройства адаптации, и
функции
медиации, которую выполняют устройства медиации.
Функции адаптации и реализующие данную функцию устройства адаптации
(Adaptation Device, AD) обеспечивают информационный обмен между физическими
элементами, не поддерживающими стандарты TMN, и элементами сети или
операционной системой, которые соответствуют принципам TMN. В этом случае
необходимо применение физического устройства, которое называется Q-адаптером
(Q-adapter, QA).
Q-адаптер обеспечивает подключение элемента сети с несовместимым с TMN
интерфейсом к Q-интерфейсу TMN. Характерным примером такого взаимодействия
может быть подключение устаревшей электромеханической или квазиэлектронной
АТС к сети TMN. Адаптер поддерживает интерфейсы TMN, интерфейс к не-TMN
системе, а также при необходимости внешние интерфейсы для вывода информации
(например, аварийной). Выделяют также X-адаптер (X-adapter, XA), который
позволяет организовать обмен информацией между операционной системой TMN и
несовместимой с TMN операционной системой, которая не поддерживает
стандартный коммуникационный механизм TMN. Скажем, унаследованная
автоматизированная система технической эксплуатации с устаревшим типом
программного управления может взаимодействовать с операционной системой TMN
через X-адаптер.
В свою очередь, устройства медиации MD осуществляют трансформацию
данных при обмене между физическими блоками TMN, которые поддерживают
несовместимый механизм обмена информацией. Здесь также различают Q-медиатор
(Q-Mediator, QM) и X-медиатор (X-mediator, XM). Q-медиатор поддерживает
Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

54

соединения внутри TMN, а X-медиатор – между операционными системами
различных TMN. Адаптеры и медиаторы могут выполнять функции преобразования
форматов данных.
Существует техническая возможность разработки на базе одного физического
блока нескольких функциональных блоков одного и того же или различных типов.
Например, операционная система может быть использована для выполнения
нескольких OSF, а также применяться для реализации OSF, MF и WSF. В случае,
если блок построения реализует несколько функциональных блоков различных
типов, выбор наименования блока определяется его преобладающим
использованием. Функциональное разделение должно осуществляться так, чтобы
взаимодействие осуществлялось через четко определенные опорные точки.
В табл. 3.2 показано, с помощью каких физических блоков построения могут
быть реализованы те или иные функциональные блоки.
Таблица 3.2 (Рек. МСЭ-Т M.3010)
NE

NEF

TF

OSF

WSF

Об

Вз

Вз

Вз

Об

Вз

QA,XA,QM, XM

Об

OS

Вз

Об

WS
Примечание. Об – обязательно; Вз – возможно.

3.2.3. Интерфейсы TMN

Интерфейсы могут рассматриваться как физическая реализации опорных
точек TMN. В то время как опорные точки можно сравнить с услугами управления,
интерфейсы можно сравнить со стеками протоколов, которые реализуют эти услуги.
Интерфейсы осуществляют реализацию физического взаимодействия
между
различными элементами (физическими блоками) TMN или взаимодействие TMN и
внешнего окружения. С точки зрения модели ВОС интерфейсы обеспечивают
интероперабельность, т.е. позволяют сохранять взаимодействие между различными
открытыми системами или между уровнями открытых систем. Для TMN это означает
организацию
взаимодействия
Интерфейс
между физическими блоками TMN
безотносительно к типу устройств
и фирме-поставщику. При этом
стандартный
интерфейс TMN
Концептуальное
Физическая
описание
реализация
получает то же самое имя
опорной точки
опорной точки
(записывается
прописными
буквами), что и соответствующая
опорная точка.
Интерфейсы TMN можно
P-Part
M-Part
рассматривать в двух аспектах: в
аспекте концепции TMN и в
Рис. 3.10 Взаимосвязь между опорной
физическом
аспекте.
точкой и интерфейсом

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

55

Концептуальный аспект описания интерфейса определяется посредством опорной
точки. В этом аспекте интерфейс характеризуется подсистемой сообщения M-Part
(message part), в то время как в физическом аспекте – подсистемой протокола Р-Part
(protocol part). В рамках модели ВОС, которая используется в TMN, M-Part
определяет структуру сообщения, посланного или полученного от управляемого
объекта, т.е. фактически сообщения CMIS согласно Рек. МСЭ-Т X.710. P-Part
определяет стек протоколов, используемый для передачи этого сообщения.
Последнее определяет профиль интерфейса, т.е. совокупность протоколов
различных уровней модели ВОС, которые поддерживают данный протокол.
Взаимосвязь опорных точек и соответствующих им интерфейсов выглядит
следующим образом:
Опорная точка

Интерфейс

q

Q
X
x
F
f
Спецификации интерфейсов TMN разрабатывают различные организации, в
том числе МСЭ-Т, ETSI, TMF. Спецификации интерфейсов, как правило, содержат
формальное описание управляемого объекта с помощью выбранного метода
описания, а также сценарии использования интерфейса, причем эти сценарии не
входят в состав рекомендаций TMN. В спецификациях указываются все ресурсы,
доступные для управления, и способы доступа к информации управления данными
ресурсами. Спецификация интерфейса TMN определяет функции интерфейса, но не
содержит описание протоколов, которые используются для обмена информацией
через интерфейс. Методология, которую нужно применить при проектировании и
разработке интерфейсов TMN, подробно описана в Рек. МСЭ-Т M.3020 и в главе 6.
Согласно этой методологии, проектирование интерфейса TMN начинают с
определения услуг управления, которые желательно получить. Далее услуги
управления разделяют на отдельные компоненты, а компоненты услуг управления –
на функции управления. Функции управления с помощью объектноориентированного подхода представляют в виде классов объектов управления (см.
главу 4). При этом возможно использование средств моделирования и
конструирования объектов управления.
После моделирования осуществляется объединение разработанных классов
объектов. На этом этапе подтверждается, что первоначально спланированные
услуги управления поддерживаются классом объектов управления, который создан
разработчиком. На всех этапах разработки безусловно учитываются содержание
процесса управления, правила и цели управления.
Услуги управления и функции, необходимые для разработки
информационной модели управления, документированы в Рек. МСЭ-Т M.3200 и
M.3400. Эти рекомендации в большей степени носят информативный, чем
нормативный характер. Поскольку интерфейсы TMN созданы на базе объектноориентированного подхода, новые разработки интерфейсов должны учитывать
основную сетевую информационную модель согласно Рек. МСЭ-Т M.3100. Более
подробно спецификации интерфейсов и связанных с этим проблемы
рассматриваются в главе 6.
Существует три стандартных интерфейса TMN: Q-интерфейс, F-интерфейс и
X-интерфейс.
Q-интерфейс характеризуется прежде всего тем, какая часть информации об
управляемом объекте используется совместно операционной системой и элементом

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

56

сети (другой операционной системой). Другими словами, Q-интерфейс определяет,
какие телекоммуникационные ресурсы и операции элемента сети будут «видны»
TMN, а какие ресурсы «не видны». Q-интерфейс применяется также на стыках OS –
NE и OS – OS.
F-интерфейс позволяет соединить рабочую станцию WS и физические блоки
TMN, которые поддерживают реализацию OSF и TF. Соединение осуществляется
через сеть передачи данных.
X-интерфейс поддерживает взаимосвязь TMN и других внешних систем,
включая, разумеется, иные TMN, а также используется для управления
предоставлением коммерческих услуг. Это возможно при наличии в
соответствующих системах
интерфейсов, взаимодействующих с TMN. Для
передачи информации во внешнее окружение уровень информационной
безопасности для X-интерфейса должен быть выше, чем для Q-интерфейса. По
аналогии c Q-интерфейсом, X-интерфейс определяет для внешних систем видимую
часть «айсберга» TMN и порядок доступа к ее ресурсам [1,2,4].
3.2.4. Информационная архитектура TMN

На технологическом уровне управление телекоммуникациями представляет
собой
обработку
информации,
поступающей
от
элементов
сети,
специализированными программными приложениями. Необходимо осуществлять
информационный обмен между многочисленными устройствами и оборудованием
связи, операторами и провайдерами услуг. Поэтому в настоящее время управление
телекоммуникациями реализуется на базе распределенных программных
приложений. Информационная архитектура TMN, в рамках которой осуществляется
обмен данными по управлению, основана на модели управления согласно стандартам
ВОС (Рек. МСЭ-Т X.720), использует объектно-ориентированный подход и
оказывает непосредственное влияние на спецификацию интерфейсов TMN.
Ключевыми элементами информационной архитектуры являются информационные
элементы, модели взаимодействия элементов и собственно информационные
модели.
Информационные элементы с точки зрения объектно-ориентированного
подхода и принципов ВОС моделируются как управляющие и управляемые объекты.
В дальнейшем рассматривается описание управляемого объекта как наиболее
существенной части информационной архитектуры TMN. Согласно модели ВОС
описание управляемого объекта осуществляется с помощью контура управляемого
объекта (managed object boundary). В этом контуре указаны характеристики объекта,
доступные для управления, в частности (см. рис. 3.11):
Управляемый
объект
Действия или
операции

Глава 3. Версия 2.0

Атрибуты и
поведение
(режимы
работы)

Уведомления
(извещения)
или
сообщения

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

57

Рис. 3.11 Управляемый объект



атрибуты, которые описывают свойства объекта;
операции, которые могут выполняться на объекте;
поведение или режим работы объекта, которые задаются согласно операции;
сообщения или уведомления, которые выдаются объектом.
Как видно из сказанного, описание объектов управления достаточно
абстрактно и может относиться к самым разнообразным сетевым элементам.
Формально МСЭ-Т рекомендует для описания структуры и поведения управляемых
объектов использовать «Общее определение объектов управления» (Guidelines for
the Definition of Managed Objects, GDMO) согласно Рек. МСЭ - Т X.722.
Управляемый объект наиболее точно характеризуется своим состоянием и
взаимоотношениями с другими объектами. Эти характеристики представлены в
атрибутах управляемого объекта, доступ к которым можно получить с помощью
операций, которые выполняются по команде управляющего объекта. При описании
объекта управления определяется набор уведомлений (acknowledgement), которые
посылает управляемый объект для оповещения управляющей системы о событиях,
связанных с данным объектом.
Для описания синтаксиса данных, передаваемых между управляющим и
управляемым объектами, используется специальный метаязык описания данных. Для
описания семантики операций над атрибутами и объектами применяются шаблоны
поведения объектов, которые обычно записываются на естественном языке.
Подробно данный вопрос рассматривается в главе 4. Управляемый объект может
быть создан или удален внешними командами, если это разрешено GDMO. Этот
документ также допускает, что заданный объект может наследовать все операции,
уведомления и поведение других объектов. При определении новых объектов
предполагается, что стандартные определения при возможности используются
повторно. Это один из сложных аспектов моделирования объектов ВОС. Набор
инструментальных средств моделирования GDMO упрощает такую задачу.
Управление ВОС осуществляется с помощью модели взаимодействия агент –
менеджер [7,8,12,16](рис. 3.12).
Управляющая
система

Интерфейс
управления
менеджер-агент,
напр. Q

Управляемая система

Управляющие
команды
(Get,Set,Create)

Менеджер

Протокол
управления
Уведомления
(notifications),
ответный
сообщения
(replays)

Интерфейс
с M IB

Информационная
модель
ресурса

Фильтрация
мониторинг

Агент

Функциональный
интерфейс

Информационная
модель ресурса
с его рабочими
характеристиками

Управляемые
физические ресурсы
(оборудование связи)

Рис. 3.12 Взаимодействие менеджера и агента в информационной архитектуре TMN

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

58

Считается, что программное приложение, которое выдает команды
управления и принимает уведомления, является программой-менеджером.
Приложение, установленное на элементе сети, выполняющее управляющие команды
и посылающее уведомления от имени управляемых объектов, является программойагентом. Менеджер устанавливает взаимосвязь с агентом для осуществления
управляющего взаимодействия. Возможное нарушение такой взаимосвязи может
быть обнаружено обеими сторонами.
Как только связь между менеджером и агентом установлена, может начаться
обмен управляющей информацией. Программа-менеджер может потребовать
выполния операций «Создать» (CREATE), «Удалить» (DELETE), «Выполнить»
(ACTION) в отношении управляемых объектов в целом, а также операций
«Получить» (GET) и «Установить» (SET) относительно атрибутов управляемых
объектов, согласно GDMO. В итоге, получив команду начать ту или иную операцию,
программа-агент выполняет требуемое действие на управляемом объекте и посылает
менеджеру сообщение о результатах или подтверждение о выполнении операции.
Программа−агент выступает своего рода посредником между менеджером и
управляемым ресурсом. При этом агент с помощью функционального интерфейса
взаимодействует с управляемыми физическими ресурсами. Описание ресурсов агент
поддерживает с помощью информационной модели управляемого ресурса. В этой
модели отражаются рабочие характеристики ресурса, на которые можно
воздействовать или которые можно контролировать в процессе управления. С другой
стороны, менеджер также поддерживает информационную модель управляемого
ресурса, т.е. информационные модели агента и менеджера в основном одинаковые.
Но информационная модель менеджера может быть более точна в силу того, что
информация менеджера является «очищенной», нормализованной, упорядоченной.
Это происходит благодаря агенту, который фильтрует поток данных в сторону
менеджера от незначительных ошибок, искажений. Кроме того, информационная
модель менеджера включает модели нескольких ресурсов, т.е. модель менеджера
более глобальна, чем модель агента. Модель агента часто называют базой данных
управляющей информации (Management Information Base, MIB). Разумеется
менеджер также поддерживает MIB, но база данных менеджера вторична по
отношению к базе данных агента по причинам, которые были перечислены выше.
Для обновления своей базы данных менеджер всегда запрашивает агента. В MIB
хранятся атрибуты управляемых объектов, описания классов, которые соответствуют
элементам сети. MIB является по сути абстрактным описанием характеристик
управляемых ресурсов, т.е. оборудования и систем связи, и позволяет хранить
описание действий (операций управления), которые можно осуществлять над
управляемыми объектами. Другими словами, MIB позволяет программным
приложениям управления (в первую очередь агенту, затем менеджеру), получать
информацию об управляемых объектах.
Управляемые объекты могут самостоятельно выдавать уведомления,
например, о своем состоянии при наступлении некоторых событий, которые заданы в
соответствующих описаниях GDMO. Уведомления обычно означают, что на объекте
произошло что-либо, представляющее интерес, например, создание, удаление
объекта или изменение значений его атрибутов. Агенты доставляют уведомления
менеджеру либо непосредственно, либо через дискриминаторы (descriminators)
передачи событий. Дискриминаторы являются управляемыми объектами,
фильтрующими события, поступающие от агентов. Фильтрация гарантирует прием
менеджером информации только о событиях, представляющих интерес, или согласно
приоритета сообщения. Например, сообщения о критических неисправностях будут

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

59

направлены менеджеру в первую очередь, а сообщения о незначительных
неисправностях смогут поступить только после отработки сообщения о критических
неисправностях.
Другой важный аспект управления системами в TMN состоит в том, что
передача управляющих команд основана на модели асинхронной передачи
сообщений.
Все операции, осуществляемые над управляемым объектом, могут быть
разделены на четыре примитива (или типа): запросы, ответы, подтверждения и
указания. Эти примитивы используются следующим образом:
• чтобы выполнить операцию, менеджер посылает управляющую команду
(сообщение-запрос);
• когда такое сообщение поступает агенту, оно принимается как сообщениеуказание;
• агент выполняет требуемое действие и может послать сообщение-ответ;
• сообщение-ответ принимается менеджером как сообщение-подтверждение.
Агент посылает ответное сообщение, если в исходном запросе затребовано
подтверждение. Операции GET (получить), CANCEL-GET (отменить получение),
CREATE (создать) и DELETE (удалить) подтверждаются всегда; операции SET
(установить), EVENT-REPORT (сообщение о событии) и ACTION (выполнить) могут
подтверждаться или нет. С учетом использования технологии «агент-менеджер»
функциональная архитектура TMN имеет вид, представленный на рис. 3.13.
G
W SF

F

X
A

M

M

A

OSF

OSF

M

X

M

Q
Q
M

Q

Q

A

Q

TF
A

A
TF

M

M

M

Q
Q

A

A

A

A

TF

NEF

TF

NEF

M

M

Рис. 3.13. Функциональная архитектура TMN, менеджеры (М) и агенты (А)
В целом информационная модель управления в TMN представляет собой
Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

60

информационную конструкцию, которая поддерживается функциональными блоками
менеджеров и распределенными знаниями по управлению (Shared Management
Knowledge, SMK), которые могут быть распределены по нескольким узлам TMN.
Этот случай рассматривается в разделе 6.3 на примере интерфейса X.
Информационная модель управления [11] представляет собой абстрактное
описание сетевых ресурсов, доступных для управления, и соответствующих
операций управления, определяет стандарты для содержания информационного
массива, который появляется в ходе сетевого управления. Информационная модель
относится к прикладному уровню модели ВОС, поэтому при ее разработке требуется
организовать взаимодействие с другими приложениями 7-го уровня модели ВОС,
которые используются для хранения, поиска и обработки информации.
3.2.5. Логическая многоуровневая архитектура TMN

В рамках концепции TMN существует определенная иерархия
«обязанностей», связанных с управлением теми или иными объектами. Такая
иерархия может быть описана с помощью термина «уровень управления»;
соответственно архитектура, которая описывается с помощью уровней, называется
логической многоуровневой архитектурой (Logical Layered Architecture, LLA) TMN.
Достаточно быстро концепция уровней управления стала наиболее важным и часто
упоминаемым в литературе видом архитектуры TMN. Впервые описание этого вида
архитектуры появилось в 1992 г. как приложение к Рек. МСЭ-Т M.3010. Позднее
описание данной архитектуры перешло в основной текст рекомендации версии 1996
г. и сохранилось в версии 2000 г.
Появление LLA обусловлено тем, что задачи сетевого управления достаточно
сложны и многоплановы. Для упрощения управления и разграничения полномочий
между различными участниками процесса управления функциональные возможности
TMN вместе с необходимой информацией могут быть разбиты на ряд логических
уровней. Принцип такого иерархического разбиения [14] показан на рис. 3.14.

Уровень 1

М енеджер

SAP
Агент

М енеджер

Уровень 2

SAP
Агент

Уровень 3

Рис. 3.14 Декомпозиция функциональности управления
(SAP – точка доступа к услуге)
Уровень 2 на границе между уровнями 1 и 2 предоставляет услуги по
управлению уровню 1. Предоставление услуг реализовано с помощью передачи на
вышестоящий уровень 1 информации управления, которая формируется с помощью
программы-агента уровня 2. Управление, которое осуществляется на уровне 1, не
Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

61

требует детальной и подробной информации о состоянии уровня 2; программа−агент
на уровне 2 будет формировать только ту информацию управления, которая
необходима для принятия решений на уровне 1 по принципу «знать только то, что
нужно для работы». Принцип иерархического представления может применяться
рекурсивным способом − предоставление информации управления уровнем 3 может
быть обеспечено для уровня 2 с помощью программы−агента уровня 3.
Принципиально важно отметить, что по аналогии с моделью ВОС уровень 1
не может напрямую управлять уровнем 3, для этого уровень 1 получает услуги
управления от уровня 2, а уровень 2, в свою очередь, получает услуги управления от
уровня 3. Другими словами, уровень 1 управляет уровнем 3 через уровень 2.
Функциональные возможности сети TMN могут быть разбиты на следубщие
уровни:
• элемента сети (Network Element Layer, NEL);
• управления элементом (Element Management Layer, EML);
• управления сетью (Network Management Layer, NML);
• управления услугами (Service Management Layer, SML);
• управления бизнесом (Business Management Layer, BML).
Эти уровни, включая их функциональные блоки и опорные точки, показаны на
рис. 3.15.
Логическая
многоуровневая
архитектура
Уровень
управления
бизнесом, BML

Функциональная
архитектура

Физическая
архитектура

Система
управления
бизнесом, BMS

Business
OSF
B-OSF

q

Уровень
управления
услугами, SML

x

Service
OSF
S-OSF

Система
управления
услугами, SMS

q

Уровень
управления
сетью, NML

Network
OSF
N-OSF

x

Система
управления
сетью, NMS

x

Система
управления
элементами, EMS

q

Уровень
управления
элементом, EML

Element
OSF
E-OSF

q

Уровень
сетевого
элемента, NEL

Network
Element
NEF

x

Рис. 3.15 Логическая многоуровневая архитектура TMN и ее связь с другими
архитектурами

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

62

Реализации TMN могут включать бизнес-функции (Business Operation System
Function, B-OSF), которые имеют отношение ко всем управляемым сетям/системам
связи и осуществляют общую координацию делового управления оператора связи.
Сервисные функции (S-OSF) на уровне управления услугами имеют
отношение к услугам связи, предоставляемым с помощью технических средств
одной или нескольких сетей электросвязи и обеспечивают интерфейс с абонентом
или клиентом.
Сетевые функции (N-OSF) реализуют функции управления приложениями
TMN, которые ориентированы на управление сетями связи. При этом N-OSF
взаимодействуют с функциями элементов сети (E-OSF). В свою очередь, E-OSF
обеспечивают управление отдельными сетевыми элементами. В итоге N-OSF и EOSF
обеспечивают
управление
сетью
электросвязи
на
уровне
телекоммуникационного оборудования и предоставляют сетевую информацию по
запросам сервисных S-OSF.
Функции элемента сети (Network Element Function, NEF) входят в состав
уровня EML и управляются с его стороны или со стороны уровня сетевого
управления.
В рамках LLA предполагается, что программы-менеджеры OSF любого
уровня могут управлять OSF-агентами, находящимися на том же уровне, либо на
нижерасположенном уровне. Это управление как в пределах данной TMN, так и
между разными TMN осуществляется через опорные точки q или х соответственно.
Управление агентами NEF осуществляется с помощью E-OSF либо OSF других
уровней.
Уровень элемента сети – это собственно телекоммуникационное
оборудование с функционирующей программой-агентом для сбора информации и
обработки управляющих воздействий, поступающих от уровня управления
элементом.
Уровень управления элементом сети. Отдельные элементы сети
управляются с помощью E-OSF на уровне управления элементом сети. На этом
уровне осуществляется взаимодействие со специфическими функциями данного
оборудования, реализация которых зависит от поставщика оборудования. В
результате специфические функции оборудования «скрываются» уровнем
управления сетевым элементом от других уровней модели TMN.
В качестве примера можно привести следующие функции, выполняемые на
уровне управления элементом сети:
• обнаружение ошибок и неисправностей телекоммуникационного оборудования и
систем связи;
• измерение потребляемой мощности;
• измерение температуры оборудования,
• измерение задействованных ресурсов оборудования связи, например, загрузки
центрального процессорного элемента, наличия свободного места в буфере
передачи/приема, длина очереди и т.п;
• регистрация статистических данных;
• модификация программного обеспечения.
Следует отметить, что OSF на уровне управления элементом и NEF могут быть
выполнены в виде единого или различных программно-аппаратных модулей.
Уровень управления сетью осуществляет функции управления, касающиеся
взаимодействия между многими видами телекоммуникационного оборудования. На
уровне управления сетью внутренняя структура элемента сети «невидима», это
означает, к примеру, что состояние буфера устройства приема/передачи, температура
Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

63

оборудования и т.п. не могут напрямую контролироваться и управляться этим
уровнем.
Примеры функций, выполняемых на уровне управления сетью:
• создание полного представления о сети (информационная модель сети);
• создание обходных путей установления соединения с целью поддержки QoS для
конечных пользователей;
• модификация и обновление таблиц маршрутизации;
• мониторинг загрузки линий и каналов связи;
• оптимизация возможностей сети для повышения эффективности использования
средств и систем связи;
• обнаружение неисправностей и ошибок программного обеспечения.
OSF на уровне управления сетью используют информацию управления,
которая не зависит от производителей систем. Эта информация обеспечивается OSF
на уровне управления элементом сети. OSF на уровне управления сетью
функционирует в виде программы-менеджера, а на уровне управления элементом
сети – в виде программы-агента.
Уровень управления услугами (сервисами) затрагивает вопросы управления,
которые непосредственно касаются пользователей услуг связи. Это могут быть
клиенты оператора, абоненты сетей связи, а также администрации операторов связи
или провайдеров услуг. Управление услугами осуществляется на основе
информации, которая предоставляется уровнем управления сетью; при этом уровень
управления услугами «не видит» детальную внутреннюю структуру сети.
Маршрутизаторы, АТС, системы передачи не могут непосредственно управляться с
уровня управления услугами.
Примеры функций управления, которые выполняются на уровне управления
услугами:
• контроль качества услуг связи (задержки, потери, и т.д.);
• учет объема использования услуг связи;
• добавление и удаление пользователей;
• назначение сетевых адресов и номеров телефонных аппаратов;
• сопровождение группы адресов или номеров, например, присоединенного
оператора.
Формулировка и использование понятия «управление услугами» является
одним из наиболее
ценных вкладов концепции TMN в разработку системы
управления услугами и сетями связи.
Управление услугами может использоваться во многих случаях.
Первый случай – два оператора обмениваются информацией по управлению
для того, чтобы управлять своими взаимосвязанными сетями (межоператорское
управление). Из соображений безопасности и в условиях конкуренции на рынке
связи каждый из этих двух операторов будет скрывать внутреннюю структуру своей
сети связи от другого оператора. Обмен будет осуществляться только в той части
информации управления, которая необходима для обеспечения качества
предоставления услуг связи. К примеру, это могут быть данные о приоритетах
абонента или профиль услуг абонента.
Второй случай – оператор, который
предоставляет определенные виды
связи, использует транспортную сеть другого оператора, чтобы соединить свои
элементы сети. Данный случай характерен для поставщиков услуг IP-телефонии или
других IP-сервисов, которые использует сеть оператора ATM, чтобы осуществить
соединение IP-маршрутизаторов (рис. 3.16).

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

Уровень
управления
бизнесом

64

TM N оператора
IP-телефонии

TM N оператора
ATM сети

OSF

OSF

X

Уровень
управления
услугами

OSF

Уровень
управления
сетью

OSF

OSF
X

OSF
X

Уровень
управления
элементом
сети
Уровень
элемента
сети

OSF

OSF

NE

NE

Рис. 3.16 Взаимодействие TMN различных операторов (по материалам [6])
Здесь можно организовать три опорные точки x (и соответственно три
реализации интерфейса X) на пути от поставщика услуг IP-телефонии до оператора
транспортной сети, например сети ATM [6,14].
На стороне оператора сети ATM все опорные точки соединяются с уровнем
управления услугами. Следовательно, оператор сети ATM не позволяет поставщику
услуг IP-телефонии контролировать и изменять внутреннюю организацию ATM сети.
Для поставщика услуг IP транспортная сеть ATM является отдельным элементом
сети IP-телефонии; этим объясняется наличие опорной точки стыка на уровне
управления элемента сети провайдера IP-телефонии. В случае, если поставщику
услуг IP-телефонии предоставляется возможность выбора альтернативных
маршрутов или пропускной способности на сети ATM, необходимо создать опорную
точку на уровне управления сетью. Учитывая, что пропускная способность сети
ATM оказывает серьезное воздействие на QoS сети IP-телефонии, опорную точку
стыка можно создать на уровне управления услугами.
Третий случай – оператор сети связи обменивается информацией управления
с системой управления, которая принадлежит одному из клиентов оператора или
присоединенному оператору связи. Основной оператор скрывает внутреннюю
структуру сети от клиента и обеспечивает доступ только к общей информации о
качестве предоставленных услуг.

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

65

Уровень управления бизнесом отвечает за управлением целым
предприятием. Этот уровень следует рассматривать в широком контексте, при этом
управление связью – это только часть управления бизнесом. Управление бизнесом
можно рассматривать скорее как целевую установку, нежели как достижение цели.
По этой причине управление бизнесом связано скорее со стратегией управления
сетями электросвязи в экономическом аспекте, нежели с оперативным управлением
сетью. Часть вопросов управления бизнес-процессами обсуждается в главе 7.
На основании логической многоуровневой архитектуры TMN можно
осуществлять логическое разбиение систем управления (Management System, MS),
которые являются физической реализацией системы управления на принципах TMN.
Системы управления представляет собой распределенную или централизованную
вычислительную систему, которая состоит серверных ЭВМ, рабочих станций и
персональных компьютеров, которые связаны между собой с помощью сетевого
оборудования DCN. На серверах и компьютерах установлено разнообразное
программное обеспечение (ПО): сетевые операционные системы, ПО удаленного
доступа, системы управления базами данных (СУБД), операционные системы
рабочих станций, приложения управления электросвязью и средства
администрирования этими приложениями.
Традиционно системы управления включают в физические архитектуры TMN
вместо физических блоков. Это позволяет упростить схемы функциональных
архитектур, так как MS может содержать несколько OS. Для описания
принадлежности систем управления к уровням LLA применяются следующие
обозначения (см. рис. 3.15):
• система управления бизнесом (Business Management System, BMS)
• система управления услугами (Service Management System, SMS)
• система управления сетью (Network Management System, NMS)
• система управления элементами (Element Management System, EMS)
Администрации связи пользуются услугами управления сетями связи с
помощью программных приложений управления, которые поддерживаются
операционной
системой.
Приложения
управления
могут
осуществлять
аналитическую обработку данных и взаимодействовать с пользователями. Например,
пользователь может вывести на экран графики ежедневной нагрузки, сведения об
отказах оборудования, проанализировать качество предоставления услуг связи и т.п.
Кроме того, приложения управления осуществляют сбор, обработку данных от
оборудования и систем электросвязи, генерируют и передают управляющие
воздействие на элемент сети.
Система управления любого уровня может содержать OS как своего, так и
нижележащих уровней. Поставщики систем управления предлагают, как правило,
заказчикам определенный выбор приложений управления, который должен быть
указан в условиях заказа. Выбор приложений заказчиком может привести к
изменению исходного типа MS. Подробнее о функциях и требованиях к OS можно
ознакомиться в [7].

3.3. TMN и управление открытыми системами
Первоначально между группами по разработке концепции управления сетями
МККТТ и ISO/IEC существовало лишь небольшое сотрудничество. В результате в
1988 г. версия Рек. МСЭ-Т M.30 не имела параллельной версии рекомендации
ISO/IEC, и, следовательно, стандарты управления ISO/IEC не были сильно увязаны
Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

66

со стандартами TMN.
После публикации рекомендации M.30 сотрудничество между МККТТ и
ISO/IEC стало более тесным. Это привело к интеграции идей управления ВОС в
концепцию TMN. В настоящее время объединенная работа над концепцией TMN и
концепцией управлении ВОС выполняется в рамках TeleManagement Forum (TMF),
который является преемником Форума сетевого управления (Network Management
Forum, NMF). Обе организации являются неформальными.
Наиболее важными изменениями, внесенными в концепцию TMN в связи с
применением принципов управления ВОС, были следующие [14]:
• использование концепции «агент - менеджер», которая первоначально была
разработана ISO/IEC;
• использование объектно-ориентированного подхода, что соответствует решениям
ISO/IEC;
• использование идеи «управления доменами» (management domains).
Несмотря на описанное сотрудничество между группами по управлению
МСЭ-Т и ВОС, существуют различия в подходах к управлению в концепции TMN и
на основе принципов ВОС.
Первое различие состоит в том, что модель ВОС определяет единственную
возможную архитектуру системы управления, в то время как TMN – множество
архитектур для различных уровней представления объектов управления. В принципе
множественность архитектур управления является полезной, так как в этом случае
каждая архитектура предоставляет дополнительные возможности управления.
Однако в этом случае разработчикам необходимо быть крайне осторожными, чтобы
взаимосвязи между различными архитектурами были максимально ясными для
понимания пользователей.
Второе различие состоит в том, что TMN определяет структуру управления
для нескольких уровней ответственности за управление, которые действительно
существуют на реальных телекоммуникационных сетях. Управление ВОС не
обеспечивает такую структуру. Структура управления TMN сейчас широко известна
как логическая многоуровневая архитектура. Преимущество такой структуры
состоит в упрощении понимания целей управления; в результате методы управления
становятся проще и понятнее для администратора сети.
Третье различие состоит в том, что в противоположность ВОС концепция
TMN предлагает принципиально разделить сеть, которая является объектом
управления (сеть электросвязи), и сеть, которая осуществляет управления (TMN) c
помощью передачи данных по DCN.
Разделение сети управления и телекоммуникационной сети предотвращает
потенциальные проблемы, связанные с надежностью работы сети. Даже в случае
отказа
телекоммуникационной сети остается возможность обращаться к
неисправному объекту через сеть управления. В этом плане TMN имеет лучшие
возможности по управлению, нежели подходы, предлагаемые ВОС или SNMP.
Однако выделенная сеть управления требует дополнительного оборудования, что
приводит к росту стоимости объектов.
Следует отметить, что отказы могут происходить и в сети управления, и,
следовательно, возникает необходимость управления самой сетью управления
(метауправление) [2]. В итоге создание платформы метауправления вновь приводит к
дополнительным затратам.
Несмотря на указанные выше различия, концепция TMN в целом
соответствует модели управления открытыми системами. В результате управление
по стандартам TMN обладает недостатками, присущими модели ВОС, а именно:

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

67

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

программа, выполняющая роль менеджера или агента, исполняется, как
правило, на одном физическом элементе (узле) и не включает компоненты,
распределенные по всем узлам сети связи;

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

недостаточно развиты инструментальные средства проектирования и
разработки систем управления на базе платформы OSI.

В результате на базе платформы управления OSI в современных
конвергентных сетях невозможно достичь взаимодействий между процессами.
Поэтому, как говорилось выше, МСЭ-Т с 2000 г. приступил к публикации
пересмотренных рекомендаций по TMN (TMN-2000).
Разработка новых рекомендаций имеет следующие цели:
• обеспечение независимость информационных и функциональных моделей
управления от коммуникационной модели управления;
• обеспечение возможность использования в TMN-системах всех наиболее
распространенных коммуникационных моделей и соответствующих
протоколов – OSI (CMIP), SNMP и CORBA IDL;
• гарантии преемственности и возможность взаимодействия с системами
управления, унаследованными от «классической» TMN;
• стандартизация эксплуатационных процессов, образующих услуги
управления. В первую очередь эти стандарты будут разрабатываться для
процессов, которые выполняются совместно персоналом разных операторов;
• применение при проектировании систем управления унифицированного
языка моделирования (Unified Modeling Language, UML), который принят в
качестве стандарта для проектирования объектно-ориентированных систем.
Подробно ряд перечисленных проблем будет рассмотрен в следующих главах.

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

68

Источники информации к главе 3.
1. Гринько Д. Системы управления сетями связи. Обзор рынка, вопросы терминологии. Ч.
1. // Мир связи. Connect − 2001. − №10. − С. 74 - 77.
2. Дубенсков П.О. TMN в конце туннеля// Системы и сети связи. − 1998. − №5.
3. Иванов П.И. Управление сетями связи. − М.: Радио и связь, 1999 г.
4. Иванов П.И. Управление сетями связи. Ч. 1,2 // Сети – 1999. – № 8,9 – С. 118 - 126.
5. Нетес В.А., Трубникова Н.В. Управление сетями: стандарты, проблемы и перспективы
// Вестник связи. − 2000. − №2. − C. 83 − 87.
6. Основы управления связью Российской Федерации/ В.Б. Булгак, Л.Е. Варакин, А.Е.
Крупнов и др.; Под ред. А.Е. Крупнова и Л.Е. Варакина. − М.: Радио и связь, 1998.
7. Построение систем управления сетями связи операторов ВСС РФ. Руководящий
документ. – М.: Минсвязи России, 2001.
8. ITU−T Recommendation M.3010. Principles for a telecommunications management network.
− 2000.
9. ITU−T Recommendation M.3020. TMN interface specification methodology. − 2000.
10.

ITU−T Recommendation M.3400. TMN management functions. − 2000.

11. ITU−T Recommendation M.3100. Generic network information model. Amendment 2. −
2000.
12. Bieszczad A., Biswas P.K., Buga W. and others. Management of Heterogeneous Networks
with Intelligent Agents./ Bell Labs Technical Journal. – October-December 1999. − p. 109 –
135.
13. Lin G., Price J.D., Srinivas T.K. Network Information Models and One Vision
Architecture// Bell Labs Technical Journal. – October-December, 1998. − p.109 − 135.
14. Pras A. Network Management Architectures. − CTIT Ph. D-thesis series No. 95-02. −
Thesis University of Twente, Enschede. − With ref. ISBN 90-365-0728-6. − 1995.
15. Pras A, Bert-Jan van Beijnum, Sprenkels R. Introduction to TMN. CTIT Technical Report
99-09. – University of Twente The Netherlands.
http://www.simpleweb.org/tutorials/tmn/tmn.pdf 19.02.2001
16. Pedro Lopes R., Oliveira José Luís. Software agents in network management. − 1999.

www.det.ua.pt/Projects/difference/ work/themes/agents_mngt.pdf 1.03.02

Глава 3. Версия 2.0

А.Ю. Гребешков, 2002

Стандарты и технологии управления сетями связи

69

4. ИНФОРМАЦИОННАЯ МОДЕЛЬ СЕТИ И ПРИНЦИПЫ
ОПИСАНИЯ УПРАВЛЯЕМОГО ОБЪЕКТА

4.1

Информационная модель управления TMN

Базовые понятия, связанные с информационной моделью процесса управления,
принятые в ISO и используемые в стандартах TMN, определены в Рек. МСЭ-Т X 720.
Информационная модель управления (Management Information Model, MIM) представляет собой описание совокупности управляемых объектов. Под управляемыми объектами понимаются взаимосвязанные и взаимозависимые физические управляемые ресурсы, которые контролируются как единое целое. Это подтверждается Рек. МСЭ-Т
X.701, где указано, что управляемый объект является абстрактным представлением физического ресурса, обладающего свойствами, доступными управлению. Под ресурсами
понимаются сетевые, функциональные, информационные ресурсы, которыми собственно и приходится управлять (рис.4.1).
Статив 1
Функциональ
ные модули

Статив 1
Формальное
описание

Описание
ресурсов в MIB

Модуль 1

Модуль 2

...

Модуль N

Управляемые объекты

Управляемые ресурсы

Рис. 4.1 Соответствие управляемых ресурсов и управляемых объектов
В качестве управляемых ресурсов могут рассматриваться каналы связи, каналы
передачи, потоки сообщений, телефонная нагрузка, состав и состояние программного
обеспечения и т.п [4]. Соответственно, каждый из перечисленных ресурсов имеет
управляемые характеристики – напряжение питания, уровень сигнала, величину задержки, уровень шума, таймеры и т.п. В качестве ресурсов могут выступать сеть связи
в целом, бизнес-процессы оператора связи. Следовательно, описание управляемого ресурса соответствует логическому уровню управления, который рассматривался в главе
3. Однако информационные модели управления, вне зависимости от ресурса строятся
по единым принципам.
Информационные модели управления должны содержать только однозначные
описания функциональных возможностей и характеристик ресурсов, доступных для
системы управления. Однозначность информационной модели означает, что никакое
определение или спецификация ресурса не должны допускать альтернативной интерпретации. Поэтому способ, с помощью которого описывается и документируется инГлава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

70

формационная модель управления, имеет принципиально важное значение.
На практике идеально строгие и четкие определения управляемых объектов возможны не всегда. Это связано с постоянным развитием функциональных возможностей систем управления и ресурсов управления. По этой причине законченность (полнота) информационной модели должны интерпретироваться на основе здравого смысла разработчиков и с учётом постановки задачи создания той или иной системы управления. Для этого от разработчика требуется глубокое знание проблемной области, для
которой будет применяться модель. В итоге качество модели будет зависеть от знания,
умения и концентрации разработчиков информационной модели на ключевых моментах процесса управления [18].
Одним из ключевых понятий информационной модели управления является
класс управляемых объектов (managed object class), под которым понимается множество управляемых объектов с идентичными атрибутами, операциями, сообщениями и
сходным поведением/функционированием. Другими словами, класс управляемых объектов – это группа сущностей, обладающих сходными свойствами. Иногда говорят о
примере или образце управляемого объекта, имея в виду «типичного представителя»
того или иного класса. На программном уровне описание класса управляемых объектов
осуществляется c помощью программы-агента. В результате от того, насколько точно и
непротиворечиво выполнено описание управляемого ресурса, зависит информация и
услуги, которые программа-агент может предоставить
по запросу программыменеджера.
Детальный список и подробное описание каждого класса управляемых объектов
приведены в Рек. МСЭ-Т М.3100. В этой же рекомендации рассматривается общая информационная модель сети (generic network information model), которая является основой при разработке стандартов управления неисправностями, рабочими характеристиками, расчётами за услуги сети, а также приводится описание базовых сетевых ресурсов и их свойств. Управляемые ресурсы моделируются как управляемые объекты. Кроме того, существуют управляемые объекты поддержки, которые обеспечивают поддержку описания различных функций управления.
Рек. МСЭ−Т М.3100 определяет информационную модель управления TMN
(TMN management information model) как совокупность классов управляемых объектов,
содержащих основную информацию о сети. Информационная модель управления не
зависит от конкретного вида сети связи и сетевой топологии и создаётся для каждого
вила сети с помощью отношения наследования. Всего существует шесть основных
классов управляемых объектов, которые называются фрагментами (fragments): cеть
(nerwork), управляемые элементы (management elements), сетевые окончания (termination points), коммутация и передача (switching and transmission), переключение (cross
connections), функциональные области (functional areas) [12,14].
К примеру, фрагмент «Управляемые элементы» включает в себя классы управляемых объектов, приведенные в табл. 4.1.

Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

71

Классы управляемых элементов, содержащихся в Рек. МСЭ−Т M.3100, можно
использовать в различных сочетаниях, чтобы определить особенности архитектуры,
телекоммуникационного оборудования. В свою очередь, нижестоящие по отношению к
перечню в табл. 4.1 классы объектов могут быть доопределены так, чтобы представить
свойства специфических модулей (например, блоков питания, модулей подключения
межстанционных соединительных линий, модулей для подключения сетей передачи
данных). В результате группы данных, соответствующие интерфейсным модулям,
коммутационным элементам или процессорам, могут быть получены из некоторой базовой совокупности данных в виде последовательности модулей.
Таблица 4.1
Наименование класса
управляемого объекта
CircuitPack
equipment
equipmentR1
equipmentHolder
managedElement,
managedElementR1
managedElementComplex
software, softwareR1

Описание соответствующего управляемого ресурса
Заменяемый модуль, например, сетевой модуль, процессор, источник
питания
Физические компоненты управляемых элементов, включая заменяемые
компоненты, например, отдельные платы, микросхемные наборы
Подкласс класса управляемого оборудования; обеспечивает возможности мониторинга сообщений о неисправностях
Физические ресурсы элемента сети, которые способны включать другие
физические элементы, например полки и стативы
Элемент сети в трактовке TMN, который выполняет функции управляемого элемента
Множество (группа) элементов сети
Логические данные, которые хранятся в памяти телекоммуникационных
устройств, например программы управления и базы данных

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

Описание соответствующего управляемого ресурса

managedElement,

Управляемый элемент, т.е. узел коммутации

circuitPack
software, softwareR1

Модуль (карта)
Программное обеспечение управления АТС и административные программы, станционная база данных
Стойки, стативы, фреймы, полки

equipmentHolder
managedElementComplex

Анализ табл. 4.2 показывает, что управляемый элемент managedElement является «старшим» по отношению к другим составляющим модели. Это отношение между
элементами модели называется «включение» и подробно описывается в разделе 4.2.
С помощью данного описания коммутационный узел можно представить на
уровне заказной спецификации с точностью, соответствующей рис. 4.1. Между всеми
элементами информационной модели необходимо установить отношения наследования и вхождения, а также определить наименование объектов.
Для формально−графического представления управляемых ресурсов с помощью
классов управляемых объектов Рек. МСЭ-Т M.3100 предлагает использовать диаграмГлава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

72

мы типа «сущность-связь» (entity – relations diagram). Достоинством данных диаграмм
является возможность представления управляемых ресурсов в их взаимосвязи и взаимозависимости. Пример фрагмента диаграммы «сущность-связь» приведён на рис. 4.2.
На этом рисунке показано, что класс объектов Network (сеть) может состоять из
несколько равнозначных сетей; Network также состоит из n управляемых элементов. В
свою очередь, класс управляемых элементов (managed element) выделен на рисунке
пунктиром, т.к. в свою очередь, является множеством нижестоящих элементов. Имеется в виду, что управляемый элемент может состоять из стативов, полок, модулей, программного обеспечения и т.п., что следует из табл. 4.2.
1
Network

contains

n
1

Условные обозначения :

contains

Класс управляемых
объектов

Network

n
Характер связи между
объектами (включение,
ассоциация)

contains

Managed
elem ent

1

n

Тип связи - включение
одного объекта в
другой (в данном
случае один объект
включает в себя n
объектов )

Рис. 4.2 Фрагмент информационной модели сети (ER-диаграмма)
Качество информационной модели сети или информационной модели управления в целом можно оценить по следующим критериям [7 - 9]:
Логичное и интуитивно понятное представление управляемых ресурсов.
Классы управляемых объектов должны представлять собой логичное, непротиворечивое и интуитивно понятное специалисту описание управляемых ресурсов.
Возможность представления разнообразных операций управления. Управляемые объекты, как определено выше, должны обладать разнообразными возможностями управления. Базовые возможности должны активизироваться любыми прикладными программами (приложениями) управления. Это свойство на практике гораздо более важно, нежели поддержка специфических методов управления.
Возможность представления разнообразных операций управления для различных администраций связи. Для управляемого объекта необходимо выбирать элементы информационной модели, которые соответствуют различным фазам или этапам
процесса управления. Администрация связи требует различного представления управляемой системы, что нашло своё отражение в логической многоуровневой архитектуре
TMN. Потребители услуг связи и операторы нередко имеют об услугах связи различные представления, поэтому операции управления пользователя должны существовать
как подмножество информационной модели.
Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

73

Возможность отображения необязательных характеристик. При разработке
информационной модели необходимо определить классы управляемых объектов с неточно определенными или не всегда появляющимися на практике характеристиками.
Законченность (полнота) описания. В информационной модели должны быть
определены все свойства и характеристики класса управляемых объектов, которые необходимы, например, для обмена через интерфейсы взаимодействия. Информационная
модель даже на уровне одного объекта должна включать спецификацию всех элементов
и, в особенности, описание поведения класса управляемых объектов. Если это не выполнено, то различные интерпретации способов управления могут воспрепятствовать
взаимодействию различных управляемых объектов.
Точность и однозначность. Для специалиста должна быть доступна только одна интерпретация описания класса управляемых объектов.
Возможность многократного использования. Спецификации управляемых
объектов и отдельные компоненты спецификаций должны иметь возможность многократного применения, особенно в целях реализации интегрированной системы управления.
Развитие и масштабируемость. При разработке информационной модели необходимо иметь возможно расширения описания классов управляемых объектов.
Принципиально важным является добавление классов управляемых объектов и добавление характеристик к уже созданным классам управляемых объектов.
Абстрактность. В некоторых случаях необходимо разрабатывать абстрактные
описания, которые применимы к самому широкому набору реализаций классов управляемых объектов.
Независимость реализаций. Спецификации не должны накладывать ограничения на реализацию систем управления на уровне языков программирования и протоколов управления.
Практичность и применимость. Физический объем спецификации управляемого объекта не должен быть слишком большим; слишком большой объём описания
может на практике затруднить понимание информационной модели. Описание должно
быть понятно специалистам в проблемной области.
Качество документации. Спецификации должны быть хорошо документированы, чтобы специалист мог легко пользоваться спецификацией. Целесообразно использовать информативные комментарии для соответствующей части модели; необходим
глоссарий, который включает общепринятые значения технических терминов.
О том, какие описательные средства используются для разработки информационных моделей, чтобы удовлетворить перечисленным критериям, рассказывается в
следующих разделах.

4.2

Классы управляемых объектов и отношения между ними

При определении класса управляемого объекта в первую очередь используется
понятие «атрибута» (рис. 4.3). С помощью атрибутов определяются свойства или характеристики физического, т.е. управляемого, ресурса. Атрибуту присваивается числовое или нечисловое значение, которое может иметь простую или сложную структуру. С
точки зрения информационной модели атрибут - это элемент данных, который содержится в объекте, принадлежащем описываемому классу объектов.
Определение управляемого объекта также включает понятие «операции управГлава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

74

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

Операции
Уведомления

Уведомления

Атрибуты

Поведение
объекта

Действия

Ответы
Операции

Рис. 4.3 Описание управляемого объекта
Под поведением управляемого объекта понимаются любые правила взаимодействия объекта с внешним миром и особенности функционирования (действия) самого
объекта. Например, объекты, соответствующие различным типам АТСЭ, можно заменить одним классом объектов «Электронная АТС с программным управлением» с присущими этому классу свойствами и особенностями поведения. Данное фундаментальное свойство объектно-ориентированного подхода (ООП) позволяет абстрагироваться
от конкретных типов рассматриваемого оборудования или программного обеспечения
и имеет решающее значение при создании единого интегрированного управления различными системами и средствами связи, что, собственно, и является целью концепции
TMN.
Как уже было сказано, поведение управляемого объекта обусловлено как внешним воздействием, так и свойствами этого объекта. На управляемом объекте невозможно выполнить ту или иную операцию, если такая операция объектом не поддерживается [3].
Операции, или действия (actions), поддерживаемые классом управляемых объектов, являются точным и однозначным описанием любых способов воздействия на объект, включая ограничения работы, допустимые режимы функционирования и возможные отказы. Уведомления (notifications) выдаются управляемым объектом в случае необходимости подтвердить или отклонить выполнение той или иной операции или действия. Ответы (replies) включают описание условий, вызывающих уведомления, и собственно формат ответа на операцию.
Между управляемыми объектами существуют различные отношения и взаимосвязи. В пределах информационной модели системы управления в рамках объектноориентированного подхода имеются три типа отношений между объектами управления: вхождение (containment), наследование (inheritance) и алломорфизм (allomorphism),
которые обычно описываются графически.
Вхождение, согласно Рек. МСЭ-Т X.721, является характеристикой отношений
между управляемыми объектами, один из которых является репозиторием (т.е. хранилищем сведений) о других объектах. Например, базовый объект, соответствующий телефонной станции, может содержать описание производных объектов (например, отдельных функциональных блоков и программного обеспечения АТС). Описание каждого функционального блока может включать, в свою очередь, описание модулей, отдельных печатных плат. Следовательно, управляемый объект «Электронная АТС с проГлава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

75

граммным управлением» в этом случае является репозиторием сведений об имеющемся
программном обеспечении, аппаратных модулях, источниках электропитания, терминалах техобслуживания и эксплуатации, внешних носителях данных.
Следует отметить, что отношения вхождения очень часто иллюстрируются в виде так называемого «дерева». Дерево вхождений (сontainment tree) определяет управляемые объекты, которые содержатся в других объектах управления ( рис. 4.4).
root

system

log

discrim inator

logRecord

Рис. 4.4. Пример дерева вхождений
В представленном дереве вхождений самый высший образец управляемого объекта, согласно Рек. МСЭ-Т X.720, называется «корнем» (root) и содержит все образцы
нижестоящих управляемых объектов. Объект root функционирует как глобальная ссылка для наименований и не является сам по себе управляемым объектом Управляемый
объект system на рис. 4.4, согласно Рек. МСЭ-Т X.721, используется для представления
множества программных и аппаратных средств, которые формируют автономный объект, обладающий возможностями обработки и/или передачи информации. Управляемый объект discriminator используется для выбора необходимой информации с целью
контроля услуг по управлению. Объект logRecord − журнальная запись о каком−то событии, входит в объект log, т.е. в объект, обозначающий журналирование всех происшедших событий.
Отношение вхождения иллюстрирует прежде всего физическое взаимоотношение между управляемыми ресурсами; вхождение описывает отношение между сущностями, но не между классами управляемых объектов. Управляемый объект включается
только в один вышестоящий объект. В свою очередь, вышестоящий объект может являться составной частью ещё более высокого объекта вплоть до root.
Поведение объектов, указанных на схеме дерева, также взаимосвязано. Например, если АТС по каким-то причинам полностью выходит из строя, то в рамках отношений вхождения это означает, что из строя выходят все нижестоящие элементы (хотя
на практике нижестоящие элементы могут быть технически исправны, но не функционировать, например, по причине сбоя электропитания). Отношения вхождения используются для присвоения имени управляемым объектам.
Взаимосвязи между старшими и подчинёнными управляемыми объектами определяются с помощью одного или нескольких связанных имен. Связанное имя (name
binding) обеспечивает однозначную идентификацию управляемых объектов. Связывание имени должно осуществляться так, чтобы идентифицировать старшие (superior) и
подчиненные классы объектов в следующем формате:
[Cтарший класс]-[подчиненный класс] - (классификатор),
где классификатор включается для того, чтобы отличить многократные связывание
имени между одинаковыми классами объектов.
С помощью дерева обозначений (naming tree), которое использует описанный
выше способ связывания имени, в пределах cистемы управления обозначаются индивиГлава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

76

дуальные объекты управления. Связанное имя, определенное для старшего класса объектов, доступно для использования только данным классом объектов и не должно повторяться. В результате можно получить дерево наименований, которое известно как
информационное дерево управления (Management Information Tree, MIT).
На вершине MIT находится объект root, который функционирует как «исходный» управляемый объект, являющийся точкой отсчёта для именования нижестоящих
объектов. С учётом отношений вхождения можно сформулировать следующие основные принципы формирования MIT:

управляемый объект существует, если существует старший, т.е. вышестоящий объект;

каждый управляемый объект имеет имя в зависимости от расположения в
MIT.

Для именования управляемых объектов используются атрибуты и значения атрибутов. С помощью связывания имени устанавливаются отношения и между классами
управляемых объектов. Так, управляемый объект B может быть создан как подчинённый по отношению к объекту A только в том случае, если существует связывание имени, которое указывает на то, что класс объектов B является нижестоящим по отношению к классу объектов A. В этом случае B будет именован с использованием идентификатора атрибута и значения идентификатора, который указан к конструкции WITH
ATTRIBUTE соответствующего шаблона записи.
Различают следующие типы имён.
Утверждённое значение атрибута (Attribute Value Assertion, AVA) – комбинация идентификатора атрибута и его значения, например (согласно синтаксиса в Рек.
МСЭ-Т X.721):
AttributeValueAssertion ::=
SEQUENCE { AttributeType, AttributeValue}
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= INTEGER

Как видно из этого примера, AVA состоит из объектного идентификатора
OBJECT IDENTIFIER (OID), который принимает только целые значение INTEGER. Подробнее вопрос о объектных идентификаторах обсуждается в разделе 4.4.
Относительное начальное имя (Relative Distinguished Name, RDN) – обозначает сущность управляемого объекта, в том числе и с помощью имени вышестоящего
объекта. В качестве RDN могут использоваться одиночные AVA , например:
RelativeDistinguishedName ::= SET OF AttributeValueAssertion

Начальное имя (Distinguished Name, DN) – используется для включения в имя
объекта вышестоящего объекта; DN или FDN представляет собой имя, состоящее из
сцеплённых имён RDN начиная от root и заканчивая данным объектом в дереве MIT.
Локальное начальное имя (Local Distinguished Names, LDN) – совокупность
RDN.
Формы имени, доступные для специалиста (human readable name forms) используют форму записи имени c использованием скобок (…) или слэша /, которая отличается от Рек. МСЭ-Т X.721.
Общий принцип именования объектов в MIT можно представить так, как на рис.
4.5.

Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

77

На этом рисунке объект, соответствующий записи об аварии с идентификатором 1 (alarmRecord, recordId=1), является составной частью объекта Log c идентификатором ADM в системе system с идентификатором ATS. Если объектам сопоставить физические ресурсы, то информация на рис. 4.5 может означать, что на объекте ATS в
журнальном файле c именем ADM находится запись с информацией об аварии с номером 1, причём LDN этого объекта будет {systemId=”ATS”,logId=”ADM”, recordId=”1"}.

root

Объект A

LDN

System

system Id=ATS

RDN

Log

logId=ADM

RDN

alarm
Record

recordId=1

RDN

DN

AVA

Рис. 4.5 Пример формирования имени управляемых объектов
Наследование (inheritance) характеризует возможность определения класса объектов, который является основой, своего рода «корнем», для получения дополнительных классов.
Наследование – это отношение типа «является разновидностью». В контексте рассматриваемой тематики, связанной с телекоммуникациями, можно сказать, что класс
«Электронная АТС с программным управлением» является разновидностью телефонного коммутационного оборудования наряду с другими «родственниками», такими как
электромеханическая АТС, квазиэлектронная АТС.
Как уже отмечалось, согласно Рек. МСЭ-Т X.720 взаимосвязи классов управляемых объектов графически представляются в виде дерева наследования. Существуют
высшие классы (superior class) и подчинённые, или подклассы (subordinate class).
Подклассы входят в высшие классы.
Базовый (base)
класс

top

Класс А

Класс B
Производный
(derived) класс

Класс D

Класс С

Класс E

Класс управляемых
объектов

Отношения
вхождения
вида "is-a"

Класс F

Класс F1

Класс F2

Рис. 4.6. Дерево наследований для классов управляемых объектов
Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

78

На рис. 4.6 класс B наследует, т.е. включает все атрибуты, операции, уведомления от класса A. При этом говорят, что класс B относится (иногда это отношение называют «is-a») к классу A. Класс F2 является непрямым производным классом, относящимся к классу D.
Отношение наследования выражается с помощью дерева наследования
(inheritance tree ). По аналогии с деревом вхождения, дерево наследования разделяет
классы управляемых объектов на высшие и низшие классы (подклассы) и устанавливает связи между ними. Когда некоторый класс унаследован от высшего по уровню класса, этот «наследник» обладает всеми характеристиками высшего класса, но еще со
своими дополнительными специфическими свойствами (дополнительные атрибуты,
поведение и возможные действия).
Как и в случае других отношений в объектно-ориентированных системах, наследование определяет основную (общую) информацию о базовых классах и более конкретную частную/специфическую информацию о поведении или атрибутах управляемых объектов в производных (низших) классах. Как показано на рис. 4.6, в случае ВОС
все классы получены из класса объектов самого высокого уровня, упомянутого как tор
(вершина). Следуя этой иерархии наследований, можно видеть, что объект «класс А»
является «родственником» объекта top.
Когда какой-либо новый тип класса объектов будет добавлен к дереву наследования, к производному классу будет добавлена информация, соответствующая типу
управляемого объекта. Например, включение в дерево наследования объекта «многоточечное соединение» может повлечь за собой добавление информации, описывающей
конкретные точки/узлы, задействованные при многоточечном соединении.
Пример дерева наследования, определенного в Рек. МСЭ-Т X.721, показан на
рис. 4.7.
top

log

logRecord

system

event
logRecord

attributeValue
Change
Record

discrim inator

event
forwarding
Discrim inator

Alarm
Record

Рис. 4.7. Пример дерева наследований
В предлагаемом примере использовались следующие классы управляемых объектов, применяемые в управлении неисправностями:
• касс управляемых объектов top (Рек. МСЭ-Т X.721) представляет собой
класс, для которого все остальные классы управляемых объектов являются подклассами;
• объект Alarm Record (Рек. МСЭ-Т X.721) используется для определения
Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

79

информации, хранимой в log-файле в результате получения уведомления
о неисправности или сообщения/ответа с описанием неисправности;
• класс управляемых объектов attributeValue ChangeRecord (Рек. МСЭ-Т
X.721) используется для определения информации, хранящейся в объекте
log как результат получения уведомления об изменении значения атрибута или описания изменения значения атрибута;
• класс объектов log (Рек. МСЭ-Т X.721) позволяет хранить поступающие
сообщения о событиях в сети и местные сообщения/уведомления системы. Этот объект используется для определения принципов контроля и
журналирования информации в открытой системе;
• класс управляемых объектов «запись регистрируемой информации»
logRecord (Рек. МСЭ-Т X.721) представляет конкретные данные, которые
хранятся в объекте log; данный объект обозначает запись, содержащуюся
в объекте log;
• класс управляемых объектов event logRecord (Рек. МСЭ-Т X.721) используется для определения информации, хранимой в объекте log как результат получения уведомления о событии или описания какого-то события;
• класс управляемых объектов event forwardingDiscriminator (Рек. МСЭ-Т
X.721) используется для определения условий, которым должны удовлетворять потенциальные описания событий в сети для того, чтобы быть
направленными к пункту назначения, например к системе управления или
к оператору.
Сопоставление рис. 4.7. и рис. 4.4 показывает различие между отношениями
вхождения и наследования. На рис. 4.4. управляемый объект logRecord входит в объект
log, что объясняется тем, что запись о единичном событии (logRecord) всегда находится внутри журнального файла (log). В то же время с точки зрения классов управляемых
объектов log и logRecord относятся к различным классам, так как обладают различными
атрибутами, операциями, поведением и т.п.
Алломорфизм является ещё одним отношением, которое используется для связывания результатов функционирования/поведения определенного объекта с его описанием как экземпляра класса управляемого объекта. Например, последствия выхода из
строя абонентского комплекта значительно отличаются от последствий аварии на источниках электропитания АТС. В первом случае связь теряется для одного абонента, во
втором случае велика вероятность полной потери связи для всех абонентов. При этом и
абонентский комплект, и источник электропитания являются частью управляемого объекта «Узел коммутации».
Дополнительно к перечисленным, ещё одним принципом объектноориентированного подхода является полиморфизм. Этот принцип касается определения поведения объектов и распространения поведения вдоль иерархии наследования
«от предков к потомкам», т.е. от высших классов к подклассам.
Для описания полиморфизма зачастую используется известные понятия «операции» и «метода». У классов управляемых объектов есть операции, которые определяют
его поведение. В некотором смысле операция – это набор общих сведений о поведении
класса. При этом каждый «потомок» данного класса может предоставить метод, реализующий любую унаследованную операцию, отличный от соответствующего метода
старшего класса. Фактически операция – это описание какой-либо черты поведения
объекта, а метод – уже конкретная реализация данного поведения. Операции обязательно наследуются, т.е. распространяются вдоль иерархии без каких-либо изменений,
а методы могут видоизменяться потомками (подклассами) для реализации конкретных
деталей поведения, присущих объектам, входящим в подкласс.
Например, можно сказать, что класс «узел коммутации» имеет операцию «приём
вызова», которая обозначает возможность получения объектом данного класса (или его
Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

80

подкласса) некоторого сигнала извне. Вместе с тем у подкласса «АТСЭ с программным
управлением» метод «приём вызова» основан на изменении состояния абонентской линии, а у подкласса «Базовая станция GSM» метод «приём вызова» основан на появлении сигнала «занято» через изменение состояния в радиоканале.
Еще один принцип ООП – это модульность, т.е. вся система должна быть разделена на части, называемые модулями. Это деление более крупное, чем разбиение на
классы, – модули содержат классы в себе.
Каждое из перечисленных отношений играет важную роль в определении и внедрении информационных моделей для TMN, в особенности при описании интерфейсов TMN.
В итоге информационная модель включает в себя формализованное описание
управляемых объектов и отношений между ними. Как правило, описываются отношения вхождения, наследования и связывания имени. Способы описания рассматриваются ниже.

4.3

Описание управляемого объекта с помощью GDMO

Для того чтобы избежать возможной неоднозначности, которая может быть
свойственна информационной модели управления, МСЭ-Т принял «Общее определение
объектов управления» (GDMO), изложенное в Рек. МСЭ-Т X.722. Эти руководящие
принципы предусматривают прежде всего текстовый способ записи (обозначения) сведений об управляемых объектах по определённым правилам. В результате обеспечивается формальное описание управляемых объектов. Следует отметить, что в настоящее
время более широкое применение находит визуальный способ описания управляемых
объектов, один из которых – UML – рассматривается в главе 6 и в приложении 2.
В некоторых случаях для разработки информационной модели управления требуются классы управляемых объектов со схожей структурой, которые отличаются некоторыми параметрами. Эта ситуация возникает при необходимости описания сетей
связи с различной структурой, но состоящих из одинакового набора элементов сети, где
некоторые операции над элементами (например, над узлами коммутации и сетевыми
узлами) одинаковы. Здесь целесообразно создать такое описание сети, чтобы с помощью изменения некоторых параметров элементов, например географического местоположения узла и схем организации связи, получать разнообразные структуры сети. Для
этого вводится понятие параметризованных классов, которые также называют шаблонами [3,7,8].
Шаблон (template) или параметризованный класс (parameterized class) определяет семейство классов, отличающихся значениями некоторых формальных параметров.
Фактически шаблон − это описание множества классов с одним или более неопределенными формальными параметрами.
Шаблон может не иметь чёткой структуры и содержит неформальный текст; это
свойство часто используется, чтобы выразить всю информацию об управляемом объекте, в том числе и информацию, не попадающую под формализованные описания. Могут
быть сформированы дополнительные шаблоны для спецификации атрибутов, действий,
сообщений, параметров и поведения управляемых объектов. Но, разумеется, основным
является шаблон класса управляемых объектов.
Шаблон управляемого объекта формируется из пакетов (packages), которые содержат атрибуты (attributes), уведомления (notifications) и действия (actions). Для любого из этих элементов может быть определено их поведение (behavior). Помимо взаимосвязи классов управляемых объектов, средствами GDMO обеспечивается механизм
определения независимости шаблонов как многократно используемых компонентов.
Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

81

Этот механизм оформляется в виде пакетов (packages). Пакетам присвоены уникальные
объектные идентификаторы. Этот механизм позволяет использовать один и тот же пакет (например атрибут или сообщение) во многих классах управляемых объектов только на основе ссылки на требуемый пакет.
Пакет (package) – набор элементов модели, логически связанных между собой.
Пакет также является областью хранения данных для некоторого набора классов и других пакетов. Для разработки информационных моделей нет каких-либо ограничений на
правила, по которым разработчики могут или должны сформировать классы в пакеты.
Тем не менее существуют некоторые стандартные случаи, когда такая группировка
уместна, например тесно взаимодействующие классы, или более общий случай – разбиение системы на подсистемы. К примеру, это касается описания некоторых общих
свойств блоков абонентских линий, которые могут устанавливаться непосредственно
на АТС или на удалённых площадках.
При описании классов с помощью пакета нередко целесообразно сослаться на
класс, определенный с помощью другого пакета. Это можно сделать, импортировав
нужный пакет, в котором станут доступными все классы начального пакета. При этом
пространство имен не объединятся: для использования нового класса надо будет указать его имя с полным путем пакета, использованного для описания класса. Таким образом, обеспечивается многократное использование стандартных пакетов, что существенно экономит время на разработку информационной модели управления.
Как уже говорилось, действие − это сущность, определяющая некоторое изменение, которое может быть выполнено на управляемом объекте. В GDMO у действия есть
имя и список аргументов. Все действия, допустимые для данного класса управляемых
объектов, можно разделить на две группы: действия класса и действия представителя
класса. Действия класса – это действия, присущие не отдельным объектам класса, а
классу в целом. Отсюда, в частности, следует, что действия класса не имеют доступа к
атрибутам. Типичный пример действия класса – функция CREATE для создания нового
объекта (представителя) класса данного вида.
В GDMO объект управления описывается с использованием набора обязательных (mandatory) и условных (conditional) пакетов.
Условные пакеты доступны только тогда, когда выполнено условие PRESENT IF
(существует, если), указанное в шаблоне. При описании (спецификации) классов
управляемых объектов использование условных пакетов является дискуссионным вопросом. Преимущество условных пакетов − это способность определять многочисленные классы управляемых объектов с помощью одного шаблона. Указанное преимущество в определённой степени снижается за счёт неудобств, связанных прежде всего с
реализацией условных пакетов. Например, невозможно динамически изменить условия
применения данного пакета. С точки зрения перспективы использования объектноориентированного подхода применение условных пакетов подлежит обсуждению применительно к каждому конкретному случаю.
Формальное определение классов управляемых объектов (managed object classes)
обычно основано на шаблонах (templates), показанных на рис. 4.8.
Шаблон не может участвовать в большинстве обычных отношений между классами. Существует всего два вида отношений, в которых он может участвовать, – связи
между шаблоном и классом, порожденным от него подстановкой параметров (помечается ключевым словом «bind»), и направленные ассоциации, т.е. связи. Направленная
ассоциация (связь) должна идти в направлении от шаблона (т.е. навигация в направлении от шаблона).
Структура шаблона для описания класса управляемого объекта следующая:
<class-label> MANAGED OBJECT CLASS
[DERIVED FROM <class-label> [,<class-label>]* ; ]
[CHARACTERIZED BY <package-label> [,<package-label>]* ; ]
Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

82

[CONDITIONAL PACKAGES <package-label> PRESENT IF condition-definition
[,<package-label> PRESENT IF condition-definition]* ; ]
PRESENT IF condition-definition ;
REGISTERED AS object-identifier ;
supporting productions
сondition-definition -> delimited-string

В данном примере использовались следующие условные обозначения:
Символ «;» используется в шаблоне для обозначения окончания каждой конструкции внутри шаблона, за исключением REGISTERED AS (зарегистрирован как) и
DEFINED AS (определён как), которые соответственно обозначают начало и окончание
шаблона.
Способ записи (нотация), используемый для представления объектного идентификатора, должен соответствовать значениям, определенным в Рек. МСЭ-Т X.208
(ISO/IEC 8824) для представления значений объектных идентификаторов, т.е. запись
типа object-identifier -> <ObjectIdentifierValue> предполагает поддержку записи значения
объектного идентификатора для всех определений шаблонов в данном документе, где
ObjectIdentifierValue соответствует способу записи, принятому в Рек. МСЭ-Т X.208
(ISO/IEC 8824).
Знаки [ ] предназначены для обозначения строк шаблона, которые являются частью его определения, и могут присутствовать или отсутствовать. Если закрывающая
скобка дополнительно снабжена «звездочкой» * в виде надстрочного индекса, то содержимое в квадратных скобках может быть нулевым или повторяться несколько раз.
Условия, при которых эти части определения шаблона могут быть пропущены или повторены, зависят от определения данного типа шаблона. Практически при записи шаблона эти скобки не расставляются.
Строки, снабженные < >, которые ограничивают строку, означают, что эти строки могут быть заменены при использовании пакета. Структура и содержание замены
зависит от типа строки.
Заглавные буквы используются для обозначения ключевых слов (keywords), которые непременно должны присутствовать при каждом использовании пакета, если
только они не заключены в квадратные скобки [ ]. Квадратные скобки указывают, что
наличие данных ключевых слов необязательно.
DERIVED FROM <class-label>
- конструкция должна присутствовать во всех классах
управляемых объектов, кроме top. Аргумент <class-label> обозначает класс
управляемых объектов, из которого был получен данный класс управляемых
объектов, т.е. здесь указан ближайший высший класс для данного класса управляемых объектов. Допускается, что данный класс может иметь несколько ближайших высших классов, которые указаны в квадратных скобках [<class-label>].
CHARACTERIZED BY <package-label> - эта конструкция позволяет включать в определение класса управляемых объектов в дополнение к конструкции DERIVED FROM
один или несколько пакетов, которые содержат описание поведения объектов,
атрибуты объектов, действия над объектами или уведомления. Метка <packagelabel> обозначает пакет, который включается в класс управляемых объектов.
CONDITIONAL PACKAGES <package-label> PRESENT IF condition-definition – эта конструкция
присутствует, если один или несколько условных пакетов включены в класс
управляемых объектов. Обозначение condition-definition содержит описание условий, при выполнении которых (например, значение = «истинно») необходимо,
чтобы пакет был включен в класс. На способы описания условий и применяемые
символы, которые указываются в качестве condition-definition, нет ограничений.
Тем не менее условия должны отвечать требованиям к условным пакетам, которые изложены в Рек. МСЭ-Т X.720 и в соответствующей рекомендации ISO/IEC
Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

83

10165-1.
PRESENT IF condition-definition – эта конструкция может существовать самостоятельно и

описывает условия существования данного класса или условия включения в
описание тех или иных пакетов. Допускает неформальный комментарий.
REGISTERED AS object-identifier – данная конструкция означает, что значение objectidentifier - это глобальный уникальный идентификатор (identifier) для определения класса управляемых объектов, который используется в протоколе
управления, когда необходимо идентифицировать класс управляемых объектов.
Дополнительно к представленному шаблону описания могут применяться конструкции типа ACTIONS <actions>, NOTIFICATIONS <notifications>, которые описывают допустимые действия, уведомления для данного класса управляемых объектов. В скобках
< > указываются наименования операций.
В свою очередь, существуют шаблоны для описания пакетов, которые позволяют указать операции, выполняемые на управляемом объекте, и последовательность передачи уведомлений. С их помощью можно описать правила, по которым выполняются
операции CREATE и DELETE, а также указать способы взаимодействия управляемого
объекта с другими классами управляемых объектов.
Общий вид шаблона для описания пакета согласно Рек. МСЭ-Т X.722 приведён ниже:
<package-label> PACKAGE
[BEHAVIOUR <behaviour-definition-label> [,<behaviour-definition-label>]* ;]
[ATTRIBUTES <attribute-label> propertylist [<parameter-label>]*
[,<attribute-label> propertylist [<parameter-label>]*]* ;]
[ATTRIBUTE GROUPS <group-label> [<attribute-label>]* [,<group-label>
[<attribute-label>]*]* ;]
[ACTIONS <action-label> [<parameter-label>]* [,<action-label>
[<parameter-label>]*]* ;]
[NOTIFICATIONS <notification-label> [<parameter-label>]* [,<notification-label>
[<parameter-label>]*]* ; ]
[REGISTERED AS object-identifier].
Здесь использованы следующие конструкции!:
BEHAVIOUR <behaviour-definition-label> [,<behaviour-definition-label>]* - позволяет пол-

ностью описать поведение объекта, которое обусловлено данным пакетом. Эта конструкция характеризуется как «внешняя», сторонняя точка зрения на внутренние операции управляемого объекта. [<behaviour-definition-label>]* обозначает сущность, которая
используется шаблоном BEHAVIOUR. Данная конструкция не является обязательной.
ATTRIBUTES
<attribute-label>
propertylist
[<parameter-label>]*
[,<attribute-label>
propertylist [<parameter-label>]*]* - эта конструкция позволяет использовать атрибуты при
определении пакетов. Обозначение propertylist, которое следует за каждой меткой атрибута <attribute-label>, определяет множество операций, которые осуществляются на

управляемом объекте с учётом начальных, допустимых или требуемых значений атрибутов.
ATTRIBUTE GROUPS <group-label> [<attribute-label>]* [,<group-label> [<attribute-label>]*]* -

эта конструкция устанавливает множество групп атрибутов, которые рассматриваются
как часть пакета.
ACTIONS <action-label> [<parameter-label>]* [,<action-label> [<parameter-label>]*]* - если
эта конструкция присутствует в записи шаблона, то <action-label> обозначает множество
возможных действий, которые включены в данный пакет. Определение возможного
действия описывает, как именно действие выполняется на управляемом объекте. Если
в описании присутствует обозначение parameter-labels, то это указывает на то, какое
именно действие осуществляется на данном объекте; кроме того, с помощью parameterlabels можно указать параметры ответа (отклика) или ошибки, которые могут быть связаны с данным действием.
NOTIFICATIONS <notification-label> [<parameter-label>]* [,<notification-label> [<parameterГлава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

84

label>]*]* - эта конструкция присутствует, если в пакете есть какие-то уведомления.
Метка notification-label указывает на применяемое уведомление. Здесь могут использо-

ваться описания поведения, которые определяют условия, при которых выдаются те
или иные уведомления. Если в описании присутствует parameter-label, то это указывает
на то, какой именно класс объектов описывает уведомление или ответ.
REGISTERED AS object-identifier - этот элемент шаблона указывает на то, что значение object-identifier представляет собой глобальный уникальный идентификатор для
определения данного пакета, а также обеспечивает регистрацию поведения, атрибутов,
групп атрибутов, действий, уведомлений, которые определяются данным пакетом.
В Рек. МСЭ-Т X.722 сформированы шаблоны для описания атрибутов, групп атрибутов, параметров, связанных имен, уведомлений. С учётом требований рекомендаций МСЭ-Т необходимо чётко установить моделируемые характеристики управляемого
объекта (управляемого ресурса) и ограничения характеристик.
Подводя итог сказанному, при создании информационной модели управления
необходимо обратить внимание на следующие ключевые моменты:
• методы создания и удаления образцов классов управляемых объектов, особенно на то, какие применяются операции управления, используются ли команды CREATE и DELETE;

отношения, которые существуют между классами управляемых объектов и другими классами, включая точную спецификацию любых зависимостей между состояниями и данными (например, через значения атрибутов или Actions/Operations/ Notifications) вместе с любыми ограничениями, которые имеют
отношения к этим связям;

связи (relations), которые существуют между атрибутами внутри класса управляемых объектов, включая точную спецификацию любых зависимостей и ограничений;

атрибуты (attributes), включенные в описание классов управляемых объектов
там, где необходимо определить поведение класса;

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

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

В целом при описании управляемых объектов необходимо соблюдать такие качественные требования, как законченность, расширяемость, возможность многократного
использования, точность, контролируемость описания.
При описании поведения управляемых объектов следует соблюдать правило
структурированного описания. Для этого необходимо выполнение по крайней мере
следующих правил:
1. Моделируемая структура имеет не более трех уровней.
2. Не требуется упорядочение или повторение атрибутов.
3. Число атрибутов в каждом объекте управления не должно быть слишком большим.
Если дерево наименований не может представить все связи «по вхождению»,
необходимо представлять статическую структуру дерева с наименованием и использоГлава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

85

вать атрибуты связи или объекты, чтобы представить другие связи.
По стандартам ВОС необходимо, что бы описание различных функций систем
управления основывалось на общих классах управляемых объектов, определённых в
Рек. МСЭ-Т X.721. Например, функция сообщения о неисправностях, определенная в
Рек. X.733, поддерживается классом alarmRecord. В свою очередь, Рек. МСЭ-Т M.3100
определяет множество классов для управления сетями связи. Эти классы могут быть
доопределены для описания управления специфическими сетевыми технологиями.
Далее рассматриваются некоторые практические примеры реализации элементов
информационной модели на уровне описания классов управляемых объектов, а также
описываются способы графического и числового представления информационной модели.

Глава 4. Версия 2.0

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

86
Шаблон пакета поведения - package behavior template

Шаблон атрибута поведения- attribute behavior template
Шаблон параметра атрибута - attribute parameter template

Шаблон атрибута attribute template
Определение синтаксиса шаблона - attribute syntax
lefinition
Шаблон класса управляемых объектов managed object class
template

Шаблон группы атрибутов - attribute group
template

Определение атрибута поведения - attribute behavior
definition
Шаблон параметра действия- action parameter template

Шаблон пакетов - package template
Характеризуется
пакетом - characterized by package

Шаблон действия - action template

Постоянный пакет - conditional
package

Определение синтаксиса информации действия -action
information syntax definition
Определение синтаксиса отклика на действие - action
replay syntax definition

Шаблон уведомления notification template

Шаблон поведения уведомления -notification behavior template
Шаблон параметра уведомления - notification parameter template
Шаблон атрибута уведомления - notification attribute template

Определение синтаксиса информации уведомления
notification information syntax definition
Определение синтаксиса информации отклика - notification
replay syntax definition

Рис. 4.8. Описание классов управляемых объектов с помощью атрибутов, шаблонов и пакетов

Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

4.4

87

Примеры описания управляемых объектов

В качестве практического примера реализации принципов и правил, изложенных в
предыдущих разделах, можно привести следующее описание управляемого объекта (см.
Рек. МСЭ-Т M.3100) [12]:
network MANAGED OBJECT CLASS
DERIVED FROM
"Recommendation X.721: 1992":top;
CHARACTERIZED BY
networkPackage PACKAGE
BEHAVIOUR networkDefinition;
ATTRIBUTES networkId GET;;;
CONDITIONAL PACKAGES
userLabelPackage PRESENT IF "an instance supports it";
REGISTERED AS {m3100ObjectClass 1};
networkDefinition BEHAVIOUR
DEFINED AS
“The Network object class is a class of managed objects that are collections of interconnected
telecommunications and management objects (logical or physical) capable of exchanging information.
These objects have one or more common characteristics, for example they may be owned by a single
customer or provider, or associated with a specific service network. A network may be nested within
another (larger) network, thereby forming a containment relationship. An example of a network that is
contained in another network is a transmission sub-network. It is owned by a single Administration and
can only perform transmission functions.”;

Согласно данному описанию, управляемый объект «Сеть связи» (network) создан
на основании Рек. МСЭ-Т X.721 и является подклассом top. Данный управляемый объект
описывается с помощью пакета networkPackage. Поведение (режим работы) данного управляемого объекта определяется по метке networkDefinition. Атрибуты характеризуются меткой networkId (идентификатор сети) и над данным атрибутом допустимой является операция GET (получить), т.е. идентификатор сети устанавливается по информации от внешнего
источника. Используется условный пакет userLabelPackage, если это допускается данным
классом управляемых объектов. Данный класс зарегистрирован с объектным идентификатором {m3100ObjectClass1}. Поведение данного управляемого объекта определено в
комментарии:
«Класс управляемых объектов «Сеть связи» представляет собой класс управляемых
объектов, которые представлены совокупностью соединённых телекоммуникационных объектов (физических и логических управляемых объектов), которые способны обмениваться информацией. Эти объекты имеют одну или несколько характеристик, к примеру, они могут принадлежать одному пользователю или провайдеру или относиться к выделенным службам связи. Описываемая сеть может входить
в другую, более крупную сеть, формируя тем самым отношение вхождения. Примером такой сети может являться подсеть в системе первичных сетей передачи.
Эта подсеть передачи контролируется одной Администраций связи и предоставляет
только услуги передачи»
Более абстрактным является следующее описание класса управляемых объектов:
exampleObjectClass MANAGED OBJECT CLASS
DERIVED FROM "CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 :
1992":top ;
CHARACTERIZED BY examplePackage2 ;
CONDITIONAL PACKAGES
examplePackage1 PACKAGE
ACTIONS activate ;
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

88

NOTIFICATIONS communicationError ;
REGISTERED AS {joint-iso-ccitt ms(9) smi(3) part4(4) package(4)
examplepack1(0)} ;
PRESENT IF !conformance class 2 of underlying resource implemented
as described in ISO/IEC XXXX! ;
REGISTERED AS {joint-iso-ccitt ms(9) smi(3) part4(4) managedObjectClass(3)
exampleclass(0)};

Согласно данному описанию, управляемый объект exampleObjectClass создан на основании Рек. МСЭ-Т X.721 и является подклассом top; данный управляемый объект описывается с помощью пакета examplePackage2 и условного пакета examplePackage1. Допустимым действием для условного пакета examplePackage1 является activate (активизация),
может выдаваться уведомление об ошибке соединения communicationError; данный пакет
зарегистрирован с объектным идентификатором {joint-iso-ccitt ms(9) smi(3) part4(4) package(4)
examplepack1(0)}. В целом условный пакет существует, если выполняется следующее условие:
«Как указано в рекомендации ISO/IEC XXXX, обеспечение базовым ресурсом соответствует классу 2».
Различные аспекты описания классов управляемых объектов далее приводятся на
основании Рек. МСЭ-Т X.721, X.723 и М.3100. Классы управляемых объектов определены
в универсальной форме, предполагая возможность их многократного использования разработчиками. Далее рассматриваются некоторые элементы описания управляемых объектов, представляющие интерес с точки зрения определения поведения объекта. Комментарии относительно поведения объектов вводятся с помощью конструкции DEFINED AS ….
Информация о пакетах, например, информация относительно того, что представляет собой пакет ( пример из Рек. МСЭ-Т X.721):
пакет availabilityStatusPackage
AvailabilityStatusBehaviour BEHAVIOUR
DEFINED AS " Этот пакет описан в Рекомендации МККТТ. X.734, X.735ISO/IEC
10164-5, 10164-6 ... ";

Информация относительно атрибутов управляемого объекта, например, какое
значение должны иметь атрибуты. Пример из Рек. МСЭ-Т М.3100:
класс cross-connection
CrossConnectionBehaviour BEHAVIOUR
DEFINED AS " ... следующие определения относятся к атрибутам административного
состояния и к атрибутам операционного состояния (режима функционирования):
Атрибуты административного состояния:
(Unlocked) Разблокирование: объект Cross-Connection административно разблокирован, можно осуществлять переключение трафика.
(Locked) Блокировка: нельзя осуществить переключение трафика, атрибуты указатели
связности в терминальных точках переключения в нулевом состоянии.
Операционное состояние:
(Enabled) Разрешенное состояние: переключение выполняется в нормальном режиме
(обычное функционирование).
(Disabled) Выведенный из строя: переключение не выполняется в номральном режиме".

Определение параметра используемого атрибута. Пример из Рек. МСЭ-Т X.72:
класс top
TopBehaviour BEHAVIOUR
DEFINED AS " ... параметр miscellaneousError используется, когда обнаружена
ошибка обработки и аварийная ситуация не соответствует ни одному из определенных типов ошибки объекта управления ";

Атрибуты условия для генерации уведомлений (пример из Рек. МСЭ-Т М. 3100):
класс equipment:
EquipmentBehaviour BEHAVIOUR
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

89

DEFINED AS " ..., когда имеется изменение значения атрибута пакета …., должно выдаваться уведомление attributeValueChange, определенное в Рекомендации X.721, но
только в случае, когда изменяется значение одного из следующих атрибутов: аварийное состояние, воздействие на список управляемых объектов, метка пользователя,
версия, текущий список состояний и проблемы с функционированием. Поскольку вышеупомянутые атрибуты содержатся в условных пакетах, режим для генерации уведомления об изменении атрибута применяется только тогда, когда соответствующие
условные пакеты присутствуют в объекте управления. Когда имеется пакет уведомления об изменении состояния, пакет stateChangeNotification, определенный в Рекомендации X.721, должен генерироваться при условии, что имеется изменение значения
административного или операционного состояния (т.е. когда присутствует условный
пакет administrativeOperational State). ";

Информация о действиях, которые можно выполнять для данного атрибута (пример из
Рек. МСЭ-Т М.3100):
атрибут alarmStatusBehaviour :
AlarmStatusBehaviour BEHAVIOUR
DEFINED AS " ... используется как … индикатор значительности неисправности (от самого высокого до самого низкого):
ActiveReportable-Critical – сообщение о критической неисправности
ActiveReportable-Major – сообщение о серьёзной неисправности
ActiveReportable-Minor – сообщение о незначительной неисправности
ActiveReportable-Indeterminate – сообщение о неопределенной неисправности
ActiveReportable-Warning – предупреждение о неисправности
ActivePending - cleared – сообщение об обработанной/устранённой неисправности"

Перечисленные примеры, разумеется, не исчерпывают всего перечня формализованных описаний управляемых объектов. Однако даже поверхностное знакомство с данными описаниями показывает способы описания объекта управления в рамках информационной модели.
Для оптимизации разработок, выполненных с помощью GDMO, в 1997 г. был выполнен проект P609 «TMN Specification Support» (Поддержка спецификаций TMN). Целью
данного проекта было обобщение результатов работ, выполненных ранее институтом
EURESCOM в части, касающейся спецификации интерфейсов TMN, разработки информационных моделей систем управления. В результате была создана электронная библиотека EURESCOM с данными по информационным моделям и управляемым объектам под
условным наименованием E-MOL (EURESCOM Managed Object and Information Library).
Эта библиотека общедоступна с июля 1997 г.
через сеть Интернет на сайте
www.eurescom.org и предлагает многочисленные стандартные описания классов управляемых объектов для разработчиков систем управления. Фактически данный электронный архив представляет собой репозиторий данных по следующим объектам:
• управляемые объекты (managed object);
• функции управления (management function);
• словарь (glossary);
• группы объектов (ensembles);
• руководство по TMN (TMN guidelines).
Кроме того, в рамках E-MOL осуществляется доступ к сопутствующим материалам
по информационным моделям, в частности, к каталогу документов, содержащих описание
информационных моделей управления и предназначеных для помощи разработчикам в
процессе создания приложений для управления сетями электросвязи. Информация классифицируется по признаку организации, которая подготовила материалы: ITU-T/ISO,
ETSI, NMF, EURESCOM, IETF.
Заглавная страница E-MOL представлена на рис. 4.9.

Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

90

Рис. 4.9 Интерфейс библиотеки E-MOL (главное меню)
Интерес в библиотеке E-MOL представляет список управляемых объектов, допускающих многократное использование в одной или нескольких информационных моделях.
Этот список аналогичен библиотеке прикладных программ и состоит как из общих классов управляемых объектов, таких как «Сеть» или «Оборудование», так и специфических
классов, таких как «TariffRule» (правило тарификации), которые разработаны в рамках
проектов EURESCOM. Запись данных об управляемых объектах соответствует принципам
GDMO, которые описаны выше.

Рис. 4.10 Описание класса управляемых объектов link с помощью шаблонов
GDMO
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

91

Каждая информационная модель в E-MOL содержит вводную часть, которая в дополнение к общему описанию модели, предоставляет информацию о том, кому рекомендуется использовать данную модель, и о перспективах дальнейшей разработки этой модели. Соответствующие диаграммы, т.е. «деревья», показывают отношения наследования,
вхождения, а также имена классов управляемых объектов. Для каждой модели в электронном виде существует контентное окно, в котором с помощью механизма гиперссылок
по шаблонам можно просматривать детальную информацию шаблона, атрибута (рис.
4.10).
Описание класса управляемых объектов или информационная модель могут быть
загружены на компьютер пользователя в формате ASCII или HTML.
Подводя итог вышесказанному, можно с уверенностью сказать, что разработка
информационной модели сети или отдельного управляемого объекта является достаточно
сложным процессом, требующим специфической подготовки. Поэтому GDMO не пользуется широкой популярностью среди разработчиков. Тем не менее принципы и основные
понятия GDMO используются в рамках соответствующих рекомендаций МСЭ-Т, что и
привело к необходимости включения краткого описания данного метода в настоящую
книгу.

4.5

Объектный идентификатор

Объектный идентификатор (Object Identifier, OID) [17,19] обозначает переменную,
представленную в виде последовательности целых чисел, букв и знаков разделения, которые однозначно идентифицируют данный объект. Эта идентификация является уникальной и предназначена для обозначения класса управляемого (информационного) объекта.
Формальное определение объектного идентификатора содержится в Рек. МСЭ-Т
X.208. Объектные идентификаторы нагляднее всего представляются с помощью «дерева»
объектных идентификаторов по аналогии с отношениями вхождения и наследования (рис.
4.11).

root
ccitt(0)

recom m endation(0)

question(1)

iso(1)

adm inistration(2)

standart(0)

registrationauthority(1)

joint-iso-ccitt(2)

adm inistration
(2)

indetified-orga
nization(3)

Рис. 4.11. Представление объектных идентификаторов
Дерево объектных идентификаторов представляет собой структуру, в которой корневой каталог root соответствует общей глобальной ссылке на все имена управляемых
объектов. Основные «вертикальные» разделы ccitt, iso и joint-iso-ccitt обозначают административные полномочия соответствующих организаций, которые отвечают за размещение объектов на дугах. Каждой организации кроме идентификатора присвоен номер, указанный в табл. 4.3.

Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

92
Таблица 4.3

Организация, ответственная за присвоение Идентификатор
нижестоящих значений идентификаторов
МСЭ-Т
Всемирная организация по стандартизации
Организации, занимающиеся стандартизацией совместно с МСЭ-Т и ВОС и обладающие полномочиями по
регистрации объектов, например ANSI
(American National Standards Institute )

Номер

ccitt
iso
joint-iso-ccitt

0
1
2

Каждый информационный объект точно обозначается в рамках своей «вертикали»,
и ни один другой объект не может иметь такой же OID. Каждый объект характеризуется
уникальной строкой из компонентов, которые обозначают путь к данному объекту от
вершины root. Каждая компонента соответствует вершине дерева объектных идентификаторов. Минимальное количество компонент объектного идентификатора, как это видно на
рис. 4.11, равно двум.
В результате применения объектных идентификаторов появляется реальная возможность создания типовых управляемых объектов с уникальными идентификаторами,
которые можно многократно использовать в рамках информационной модели системы
управления. Для этого достаточно сделать ссылку на требуемый объект.
Рассмотрим, например, объектный идентификатор вида {joint-iso-ccitt ms(9) smi(3)
part4(4) managedObjectClass(3) exampleclass(0)}.

Согласно Рек. МСЭ-Т X.722 данный объектный идентификатор прежде всего указывает на то, что информационный объект, т.е. класс управляемых объектов, относится к
международным стандартам по управлению системами, о чём свидетельствует компонент
{joint-iso-ccitt ms(9)}, где ms обозначает management systems. Другими словами, описываемый
класс управляемых объектов находится в вертикали ms; цифра 9 соответствует числовому
значению идентификатора. Ниже ms находятся ветви, обозначающие пути к различным
стандартам, в совокупности составляющим общие правила управления системами (табл.
4.4).
Таблица 4.4
Обозначение
ветви
smo(0)
Cmip(1)
function(2)
smi(3)

Соответствующий стандарт управления
Обзор управления системами согласно Рек. МСЭ-Т X.701| ISO/IEC 10040
Общий информационный протокол управления CMIP согласно Рек. МСЭ-Т X.711 |
ISO/IEC 9596-1
Функции управления системами согласно Рек. МСЭ-Т X.7XX | ISO/IEC 10164-X, где X
– часть номера стандарта в принятой схеме нумерации стандартов
Структура информации по управлению согласно Рек. МСЭ-Т Rec. X.72X | ISO/IEC
10165-X, где X - часть номера стандарта в принятой схеме нумерации стандартов

В свою очередь, ветвь partX(X) обозначает принадлежность к конкретной Рек. МСЭТ X.72X | ISO/IEC 10165-X, в данном случае к Рек. МСЭ-Т X.724, где содержится требования к проформе, которая соблюдается разработчиком при использовании управляемых
объектов по стандартам ВОС. Ниже узла {joint-iso-ccitt ms(9) smi(3) part4(4)} ветви обозначают отдельные составляющие информации управления (табл. 4.5).

Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

93

Таблица 4.5
Обозначение ветви
StandardSpecificExtension(0)
asn1Module(2)
managedObjectClass(3)
package(4)
parameter(5)
nameBinding(6)
attribute(7)
attributeGroup(8)
action(9)
notification(10)

Назначение ветви
Стандартизованное расширение данной схемы, т.е. возможность ввода дополнительного описания
Расположение идентификаторов модулей ASN.1
Расположение идентификаторов классов управляемых объектов
Расположение идентификаторов пакетов
Расположение идентификаторов параметров
Расположение идентификаторов, обозначающих связывание имени
Расположение идентификаторов атрибутов
Расположение идентификаторов групп атрибутов
Расположение типов действий
Расположение типов уведомлений

В итоге на конце ветви будет находится зарегистрированный образец класса объекта управления со значением идентификатора, равным 0.
В целом для дерева объектных идентификаторов в вертикали ccitt существует распределение значений идентификаторов, представленое в табл. 4.6.
Таблица 4.6
Значение
0

Идентификатор

Назначение идентификатора

recommendation

1

question

2

administration

4

network-operator

Используется для обозначения рекомендаций МСЭ-Т. Каждая рекомендация регистрируется в формате «число от 1
до 26 и буква от A до Z»
Используется для обозначения Исследовательских групп
МСЭ-Т. Значение ветвей определяется по специальной
формуле: номер исследовательской группы + (исследовательский период x 32), где, например, для периода 1988 –
1992 г. значение «исследовательский период» = 1. Соответственно, формируются ветви для каждого вопроса, которым занимается данная исследовательская группа
За каждой администрацией связи закрепляется идентификатор согласно Рек. МСЭ-Т X.121 «Международный план
нумерации для сетей связи общего пользования»
За операторами связи закрепляется идентификатор согласно Рек. МСЭ-Т X.121 «Международный план нумерации
для сетей связи общего пользования»

Следует отметить, что в рамках Рек. МСЭ-Т M.3100 используется упрощённый
способ записи регистрации объектов, например {m3100ObjectClass 1}. В этом случае объект
зарегистрирован в ветви {ccitt (0) recommendation(0)}.

4.6

Использование ASN.1 и BER для записи данных об управляемом объекте

В рамках модели ВОС для записи данных об объектах управления используется
метод, называемый абстрактным синтаксисом записи номер один (Abstract Syntax Notation
One, ASN.1). Основные положения ASN.1 зафиксированы в Рек. ISO 8824 [15], Addendum
1 к ISO 8824, в Рек. МСЭ-Т X.208. Язык ASN.1 определён ISO как язык определения/описания типов данных (datatypes). Применение ASN.1 позволяет описать атрибуты,
параметры операций, которые специфицированы средствами GDMO, в виде данных, т.е.
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

94

констант и переменных различных типов. ASN.1 является своего рода метаязыком, который используется для обеспечения «прозрачного» обмена данными в рамках системы сетевого управления вне зависимости от применяемого языка программирования для достижения информационного единства системы. Фактически речь идёт об отображении конструкций ASN.1 в программные объекты, которые описываются с помощью языков программирования высокого уровня, например C++ или Java. В результате реализуется информационный обмен между разнородными приложениями (рис. 4.12).

Преобразование данных
для пользователя

Приложение
управления на C++

Абстрактный синтаксис
ASN.1
(описание типов данных)

Правила
кодирования BER

Протоколы для
передачи данных по
управлению
(TCP, CM IP)

Преобразование данных
для пользователя

Приложение
управления на Java

Правила
кодирования BER
Синтаксис передачи
(кодирование для
передачи)

Протоколы для
передачи данных по
управлению
(TCP, CM IP)

Рис. 4.12 Назначение ASN.1 и BER
Язык ASN.1 применяется в управлении по стандартам ISO и при управлении
объектами в сети Интернет для следующих целей [6,10,18]:

описания информации управления, в том числе для управляемых объектов и
форматов протокольных блоков данных (PDU);

описания запросов, откликов и уведомлений в протоколах CMIP и SNMP.

Структура ASN.1 совпадает со структурой языков программирования. Файл данных, описанных с помощью ASN.1, также аналогичен программному описанию данных с
использованием языков программирования. Объекты GDMO в ASN.1 кодируются в соответствии с определенными правилами. ASN.1 представляет собой гибкий способ записи
данных о характеристиках объекта, позволяет определять различные типы данных - от целочисленных переменных и строк бит до структурных данных, таких как множество и последовательности, а также иных сложных типов данных.
Правила ASN.1 предусматривают, что данные представляются в виде синтаксического дерева. При переходе от верхних уровней к нижним данные разбиваются на отдельные элементарные компоненты. Разбиение продолжается до момента, пока на нижнем
уроне не останутся только элементарные компоненты. При этом каждый элементарный
компонент соответствует определенному типу данных. При передаче данных, записанных
с помощью ASN.1, обработка осуществляется в порядке, определённом синтаксическим
деревом. При этом некоторые ветви дерева являются необязательными. Если необязательные ветви и соответствующие им форматы данных в системе не используются, то вместо
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

95

них передается нулевая информация.
Язык ASN.1 предполагает использование нескольких уровней описания данных:
метамодель, модель и экземпляр модели (данные пользователя). Центральным элементом
является модель, которая содержит типы данных, используемые в ASN.1, и позволяет
специфицировать, т.е. отнести данные пользователя к тому или иному типу ASN.1. Метамодель определяет, как описываются типы ASN.1, т.е. описывает саму модель. Наконец, экземпляр модели является конкретной реализацией того или иного типа данных, с
которыми работает приложение управления, т.е. пользователь.
С точки зрения ASN.1 тип данных представляет собой некоторый набор значений,
возможно очень большого размера; значения типа, которые задаются с помощью ASN.1,
представляют собой элемент того или иного типа данных.
В ASN. 1 имеются четыре типа данных:
• простой (simple) тип, который является единичным объектом и не включает других
структурных компонентов;
• структурный (structured) тип, который состоит из нескольких компонентов;
• маркированный (tagged) тип, который является производным от других типов;
• иные типы, в частности тип CHOICE и тип ANY (см. описание ниже).
Простой тип данных может преобразовываться с помощью комбинации простых
типов в более сложные типы данных. Типу данных, сформированных подобным образом,
может быть назначена метка (тег) для однозначной идентификации со стороны управляющих программ.
В рамках синтаксиса ASN.1 типам и значениям с помощью оператора назначения
::= могут присваиваться имена, которые можно использовать при определении других типов и значений.
Каждый тип ASN.1, кроме типов CHOICE и ANY, имеет метку - тег (tag). Формально типы, указанные ASN.1, могут рассматриваться как одинаковые, если имеют одинаковые метки. Другими словами, наименование типа ASN.1 при абстрактном описании
объекта не так важно, как важна используемая метка.
Номера тегов используются для идентификации ветвей синтаксического дерева,
заключаются в квадратные скобки [ ] и предшествуют имени элемента. Номер тега указывать необязательно только для типа SEQUENCE, если порядок следования элементов известен, т.е. отсутствует элемент OPTIONAL. В остальных случаях тегом снабжается каждый элемент.
Имеются четыре класса тегов с соответствующими идентификаторами:
• универсальный (universal) тег — для типов, значение которых одинаково во всех приложениях управления, а также для типов данных SEQUENCE или основных элементов
данных, таких как GRAPHIC STRING;
• прикладной (application) тег — для типов, значение которых является специфическим
для данной прикладной программы управления, например услуги директории согласно
Рек. МСЭ-Т X.500; типы в двух различных приложениях могут иметь одинаковые специфические для данного приложения теги и различные значения. Прикладной тег используется для определения уникального идентификатора заданного элемента;
• частный (private) тег — для типов, значение которых является специфическим для
данного приложения, а также для создания расширений существующих стандартных
значений;
• контекстно-определяемый (context-specific) тег — для типов, значение которых определяется для того, чтобы показать различие между компонентами типов с одинаковыми тегами и компонентными типами двух различных структурных типов, которые могут иметь одинаковые теги и различное значение. Контекстно - определяемый тег присваивается каждой ветви синтаксического дерева. Одинаковый номер тега используется снова и снова на различных уровнях дерева. При этом сохраняется возможность
трассировки тегов.
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

96

Типы с универсальными тегами определены в Рек. МСЭ-Т X.208. Эта рекомендация содержит номера универсальных тегов.
Типы и значения ASN.1 выражаются с помощью гибкой записи, аналогичной языку
программирования, согласно следующим правилам:
• размещение записи не имеет значения; многократные пробелы и пунктирные линии
могут рассматриваться как одиночный пробел;
• комментарии разграничиваются парой дефисов (--), либо парой дефисов и пунктирной
линией;
• идентификаторы (имена значений и полей) и ссылки на типы (имена типов) состоят из
заглавных и строчных букв, цифр, дефисов, и пробелов;
• идентификаторы начинаются со строчных букв; ссылки на типы начинаются с заглавных букв.
В ASN.1 введены базовые правила кодирования (Basic Encoding Rules, BER), которые определяют номера типов данных и присваивают номера тегов каждому типу данных.
Типы данных ASN.1 и номера тегов в BER показаны в табл. 4.7. Тип данных ASN.1 считается простым (simple types), если его поле значения непосредственно обозначает значение, которое специфицировано тегом. Простые типы также называют примитивными.
Тип данных ASN.1 считается сложным (constructed type), если его поле значения содержит комбинацию одного или нескольких простых типов. Сложные типы также называют а
структурными. ASN. 1 определяет четыре структурных типа. Структурные типы состоят
из нескольких единичных компонентов и могут иметь необязательные компоненты, которым могут быть присвоены значения по умолчанию. В табл. 4.7 указано, является ли тип
данных ASN.1 простым, сложным или тем и другим. Следует отметить, что в табл. 4.7
приведены только некоторые из 21 типов данных. Общий протокол информации управления (CMIP) поддерживает все типы данных ASN.1.
Таблица 4.7.
Номер
типа
1
2
3

Тип данных ASN.1
BOOLEAN
INTEGER
BIT STRING

Простой
Простой
Оба типа

4

OCTET STRING

Оба типа

5
6

NULL
OBJECT IDENTIFIER

Простой
Простой

7
8
9
10
11-15

Простой
Простой
Простой
Простой

17

OBJECT DESCRIPTOR
EXTERNAL
REAL
ENUMERATED
Для дальнейшего использования
SEQUENCE, SEQUENCE
OF
SET, SET OF

18
19

NumericString
PrintableString

Оба типа
Оба типа

20

TeletexString

Оба типа

16

Глава 4. Версия 2.1

тип

Сложный
Сложный

Описание типа данных
Булева переменная (0 или 1)
Произвольное целое число
Строка бит - представляет собой произвольную последовательность нулей
и единиц
Произвольная
последовательность
байтов
Нулевое значение
Объектный идентификатор представлен последовательностью целых чисел, которые идентифицируют объект

Упорядоченная совокупность одного
или нескольких типов
Упорядоченная совокупность одного
или нескольких типов
Произвольная
последовательность
печатаемых символов, строковый тип
А.Ю. Гребешков

Стандарты и технологии управления сетями связи

Номер
типа
21
23

Тип данных ASN.1

тип

VideoTexString
UTCTime

Оба типа
Оба типа

26
29

VisibleString
Для дальнейшего использования

Оба типа

97
Описание типа данных
«Универсальное координатное время»
или среднее время по Гринвичу
(GMT), строковый тип
Видимая строка символов

Например, запись вида:
ChekingAccountBalance ::= INTEGER
-- в рублях, отрицательное значение означает перерасход

характеризует проверку баланса по текущему счёту абонента. Состояние баланса характеризуется переменной ChekingAccountBalance, которая описана как целое число, причём отрицательное значение в комментарии определено как перерасход по счёту в рублях.
В качестве еще одного примера приведем запись в формате ASN.1 объектного
идентификатора, указывающего на информационную модель сети ATM, подготовленную
ETSI в 1996 году (находится в свободном доступе в E-MOL):
xAtmInfoModel OBJECT IDENTIFIER ::= {ccitt (0) identified-organization (4) etsi (0) xcoop (1996)
informationModel(0)}

Далее коротко рассмотрим некоторые типы ASN.1.
Строковые типы состоят из отдельных компонентов. При этом компоненты рассматриваются как подстроки. Это представление позволяет кодировать значение, длина
которого заранее не известна (например, длина байтовой строки из передаваемого файла).
Для строковых типов могут быть заданы ограничения по длине, т.е. по количеству символов в строке. Кроме перечисленных, может использоваться структурный тип MACRO, который позволяет создать простой тип данных как совокупность других примитивных типов данных. Кроме того, тип MACRO позволяет определять значения по умолчанию
(DEFAULT) для вновь созданных простых типов.
Структурный тип CHOICE {…} аналогичен логическому оператору «ИЛИ» (OR).
Данные внутри скобок {…} могут рассматриваться как альтернативные и в обязательном
порядке снабжаются тегами для обозначения выбранного типа. Например, элемент
TypeATS (тип АТС) состоит из элементов данных TypeATS1, TypeATS2, TypeATS3. Номера тегов при этом заключены в квадратные скобки:
TypeATS::= CHOICE { [1] TypeATS-1,
[2] TypeATS-2,
[3] TypeATS-3 }

На содержательном уровне TypeATS-1 может соответствовать электромеханической АТС, TypeATS-2 - квазиэлектронной АТС, TypeATS-3 - электронной АТС. По типу
коммутационного элемента отдельно взятая АСТ может быть отнесена к одному из указанных типов, на что указывает CHOICE.
Наличие структурного типа (индикатора) SEQUENCE {…} свидетельствует о том,
что данная ветвь синтаксического дерева и соответствующий формат данных состоят из
заданного числа упорядоченных элементов. Этот индикатор можно интерпретировать как
логическое «И» (AND). Элементы определяются соответствующим списком.
Например, элемент IndexATS (индекс АТС) состоит из определённой последовательности элементов (цифр) Digit-1, Digit-2 и Digit-3. Явно указывать теги не требуется, так
как порядок следования элементов точно определён.
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи
IndexATS ::= SEQUENCE

98

{ Digit-1,
Digit-2,
Digit-3 }

При анализе Digit-1 соответствует первой цифре индекса АТС, Digit-2 - второй цифре, Digit-3 - третьей цифре (в случае семизначной нумерации в сети связи). Соблюдение
указанной последовательности цифр важно при маршрутизации вызова на телефонной сети.
Структурный тип SEQUENCE OF указывает, что количество элементов может изменяться, однако при этом сохраняется заданный порядок следования элементов. В список могут включаться повторяющиеся элементы. При этом число элементов может быть
нулевым.
Структурный тип SET определяет, что ветвь синтаксического дерева состоит из
фиксированного числа элементов в произвольном порядке. Данный тип в какой-то степени аналогичен SEQUENCE. Тем не менее теги должны использоваться для указания на те
или иные элементы. Структурный тип SET OF определяет, что число элементов и порядок
их следования могут быть произвольными. Структурные типы SEQUENCE и SET могут
быть необязательными при описании данных. При этом после имени элемента в последовательности или во множестве указывается ключевое слово OPTIONAL. В случае, если
необязательному элементу присваивается значение по умолчанию, то вместо ключевого
слова OPTIONAL указывается DEFAULT.
Другие типы ASN. 1 обозначают как ANY. Тип ANY обозначает произвольное значение произвольного типа, который возможно определен в объектном идентификаторе
или является целочисленной переменной.
В качестве ещё одного примера можно привести описание с помощью ASN.1 формата заголовка IP-пакета [20] (рис. 4.13).
0

4
Version

8
Hlen

16

31 бит
Total length

Identification
Tim e to live

19

Type of
service
Flags

Protocol

Fragm ent offset
Header cheksum

Source address
Destination address
IP option

Padding
Data

Рис. 4.13 Формат заголовка IP-дейтаграммы
Запись заголовка с помощью ASN.1:
IpPDU ::= SEQUENCE
{
version INTEGER,
hlen INTEGER,
service INTEGER,
total-len INTEGER,
id INTEGER,
flags BIT STRING,
offset BIT STRING,
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

99

ttl INTEGER,
protocol INTEGER,
checksum INTEGER,
srcaddr INTEGER,
dstaddr INTEGER,
options OptionType OPTIONAL,
data IpDataType
}

Анализ записи ASN. 1 и формата заголовка IP-дейтаграммы приведен в табл. 4.8.
Таблица 4.8.
Поле в формате IP дейтаграммы
Version
Hlen
Type of service
Total length,
Time to live
Identificator
Flags

Fragment offset

Protocol
Header cheksum
Source address
Destination address
Оptions, padding

Data

Назначение и кодирование поля
заголовка IP-дейтаграммы
Версия IP протокола, 4 или 6
Длина заголовка, максимум 15 слов, т.е. 60
байт
Определяет способ обработки дейтаграммы,
может быть представлен целым числом
Полная длина для IP-дейтаграммы, до 65535
байт
Время жизни дейтаграммы, измеряемое как
количество пройденных маршрутизаторов,
максимум до 255 или число секунд
Уникальный идентификационный номер
дейтаграммы
Поле указывает на способ фрагментации
пакета, состоит из 4 бит. Бит 0 поля флаги
является резервным, бит 1 служит для
управления фрагментацией пакетов (0 –
фрагментация разрешена; 1 - запрещена), бит
2 определяет, является ли данный фрагмент
последним (0 – последний фрагмент; 1 - следует ожидать продолжения)
Указатель фрагмента указывает порядок
сборки дейтаграммы в случае её дефрагментации при передаче, реализован в виде двоичного числа
Указывает, данные какого протокола находятся внутри пакета, кодируется целым числом от 0 до 255
Контрольная сумма заголовка, целое число
IP-адрес источника дейтаграммы, может
быть представлен в цифровой форме
IP-адрес получателя дейтаграммы, может
быть представлен в цифровой форме
Опции IP и заполнитель – необязательные
поля, которые обеспечивают дополнительные сведения по обработке данных внутри
дейтаграммы, могут кодироваться несколькими типами данных, в том числе битовой
строкой или целым числом
Тип данных пользователя – в общем случае
произвольный тип данных

Наименование данных
ASN.1

Тип данных
ASN.1

version
hlen

INTEGER
INTEGER

service

INTEGER

total-len

INTEGER

ttl

INTEGER

id

INTEGER

flags

BIT STRING

offset

BIT STRING

protocol

INTEGER

cheksum
srcaddr

INTEGER
INTEGER

dstaddr

INTEGER

options с параметром OptionType

OPTION

data с параметром
IpDataType

НЕ
ОПРЕДЕЛЁН

Согласно [1] в SNMP существуют данные IpAddress, которые кодируются с помощью строковых данных длиной до 4 байт:
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

100

IpAddress ::= [APPLICATION 0] OCTET STRING (SIZE (4)) , где

[APPLICATION 0] соответствует тегу.

На уровне представления природа параметров данных пользователя меняется. Описания данных на прикладном уровне требуют от сервисов уровня представления (Рек.
МСЭ-Т X.216) передачи значений данных достаточно сложного типа, включая последовательность символов. Чтобы определять значения, которые будут передаваться с одного
уровня на другой, требуется определенный формат записи, который при этом не определяет способы представления данных. Поэтому этот формат дополняется спецификациями,
т.е. обозначениями одного или нескольких алгоритмов - правилами кодирования
(encoding rules), которые определяют значения байтов данных сеансового уровня, передаваемые как значения прикладного уровня (также называемые синтаксисом передачи transfer syntax). Протокол уровня представления ( Рек. МСЭ-Т X.226) может устанавливать
условия, при которых должен использоваться синтаксис передачи.
На транспортном уровне семиуровневой модели ВОС (Рек. МЭС-Т X. 200), каждый параметр данных пользователя или примитив сервиса определяется как двоичное
значение и представлен в виде последовательности байтов или бит.
Набор правил для представления данных управляемых объектов в виде битовых
последовательностей называется базовыми правилами кодирования (Basic Encoding Rules,
BER), которые описывают, как представлять или кодировать значения каждого типа данных, определенных ASN.1, в виде последовательности байт. Правила кодирования не изменяют описание формата данных [11].
В соответствии со стандартом ISO 8825 «Спецификация базовых правил кодирования для ASN.1» BER позволяют использовать в схеме кодирования теги для идентификации элементов данных как компонентов информации управления. Каждый фрагмент
(блок) информации идентифицируется с помощью предшествующего тега и номера, который определяет длину фрагмента данных. Комбинации меток могут обеспечивать вложение данные и иерархию данных. Правила кодирования BER для ASN.1, дают один или несколько способов представления любой переменной ASN.1 как последовательности байт
(рис. 4.14).

0
tag

Класс f

0

1

tag

15

7

Номер

2 3

length
(длина)

0

До 1039

Число байт
данны х (до 128)

7 8

length

Формат кода для простого
(prim itive) типа данных

contents
15
(данные)

value
(данные)

15

tag

length

value
(данные)

Формат кода
для сложного
(constructed)
типа данных

Рис. 4.14. Форматы кодирования различных типов данных с помощью BER
В процессе кодирования можно выделить три основных поля данных:
• теги (tag), которые определяют тип данных, которые содержатся в последующих полях;
• поле (length), которое обозначает число байт в поле contents/value;
• поле contents/value, которое содержит собственно передаваемые данные.
Существует три метода кодирования значений ASN.1 с помощью BER:
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи


101

простое кодирование (primitive, definite-length encoding) с определенной заранее
длиной последовательности байт в поле contents/value;
сложное кодирование (constructed, definite-length encoding) с определенной заранее длиной данных в поле contents/value применяется, если объём данных не
позволяет использовать 7 бит поля length для кодирования числа байт в поле
contents/value. Это ограничение составляет 27 = 128 байт;
сложное кодирование с неопределенной длиной данных (constructed, indefinitelength encoding).

Выбор метода зависит:
• от типа данных;
• от того, известна или нет длина поля данных;
• от того, чему равна длина данных. Максимальная длина данных согласно рис.
4.14 составляет 28*126 = 10 290 Терабайт.
Простые типы данных кодируются с помощью простого кодирования, структурные
типы - с помощью любого сложного кодирования. Для простых строковых типов можно
применять любой метод в зависимости от того, известна длина значений или нет. Для кодировки типов, теги которых указываются неявно, используются базовые методы кодирования, для типов с явным указанием тегов - методы сложного кодирования.
Поле tag при использовании BER имеет следующий формат:
- класс (class) длиной 2 бита указывает тип тега ( табл. 4.9);

Таблица 4.9
Класс, соответствующий типу тега

Значение бит
Бит 1
0
1
1
0

Бит 0
0
0
1
1

Универсальный тег
Прикладной тег
Частный тег
Контекстно-определяемый тег

- бит f указывает тип данных: если f = 0, то тип данных простой, если f=1, то тип
данных сложный;
- поле number содержит в двоичной форме информацию о номере тега. Если номер
тега меньше или равен 32, то для номера тега достаточно 5 бит. Если номер тега больше
32, то поле tag будет многобайтовым в формате, указанном на рис. 4.15.
Учитывая, что для нумерации тегов могут использоваться до 26 бит, это позволяет иметь
максимальный номер тега, равный 67 108 864; на практике в настоящее время максимальный номер тега равен 255. Последний байт в многобайтовом теге начинается с 0;

Класс f

1 1 1 1 1

1 байт

1

X X X

X X X X

...

0

X X X

X X X X

4 байт

Рис. 4.15. Многобайтовое поле tag

Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

102

- поле length содержит сведения о длине данных, т.е. о количестве байт данных в
поле contents/value. С помощью 8 бит можно указать, что общий объём данных меньше
или равен 128 байт. Если объем данных больше, то применяется «длинная форма» (long
form) записи, формат которой представлен на рис. 4.16.
Порядковые номера
1

0
1

Число байт
данны х > 128

Число байт
данны х > 128

125

...

Число байт
данны х > 128

Рис. 4.16. «Длинная форма» записи поля length
Для кодирования типов с заранее определенной длиной данных поле length имеет
формат, показанный на рис. 4.17.
1

0 0 0 0 0 0 0

Рис. 4.17. Запись в поле Length для данных неопределённой длины
Поле value/contents используется для представления того или иного значения типа
(экземпляра типа). Для сложного метода с неопределенной длиной кода, байты окончания
данных (end-of-contents octets) используются для обозначения конца записи. В других методах эти байты отсутствуют.
Можно привести следующие примеры записи в соответствии BER:
• базовый тип данных (тег UNIVERSAL2, целочисленные данные, значение –
129) выглядит следующим образом в шестнадцатеричной системе счисления: 02 02 FF 7F;
• объектный тип (тег UNIVERSAL6, объектный идентификатор со значением
{2 100 3 }) имеет вид 06 03 81 34 03.
Помимо BER имеется ещё один способ кодирования. Этот набор правил, называемый расширенными правилами кодирования (Distinguished Encoding Rules, DER), является подмножеством BER. Он присваивает уникальное кодовое значение каждому типу данных, кодированных с помощью ASN.1.
В заключение следует отметить, что кодировка ASN.1 может преобразовываться в
конструкции других языков описаний, например в структуры языка спецификаций и описаний SDL. С подробностями этой процедуры можно ознакомиться в [5,6,13].
BER не являются единственно возможными для ASN.1. В частности, в Рек. МСЭ-Т
X.690 содержится описание Canonical Encoding Rules (канонические правила кодировки),
Distinguished Encoding Rules (расширенных правил кодировки), в Рек. МСЭ-Т X.691 описывается Packed Encoding Rules (пакетизированные правила кодировки), в Рек. X.692
представлена Encoding Control Notation (контрольная нотация кодировки).
В настоящее время опубликована для обсуждения версия рекомендации X.680 под
названием «Information technology - Abstract Syntax Notation One (ASN.1): Specification of
basic notation» (Информационная технология. ASN.1. Спецификация базовой нотации). В
этой рекомендации предлагается использовать язык XML (Extensible Markup Language,
расширяемый язык разметки) и его обозначения для обозначения типов, тэгов и значений
ASN.1. Соответственно, в Рек. МСЭ-Т X.693 приводятся данные о правилах кодировки
XML. Это свидетельствует о постепенном сближении стандартов ISO и наиболее успешных программных решений для среды World Wide Web (WWW).
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

103

Список источников к главе 4.
1. Ганьжа Д. Абстрактное описание синтаксиса // Журнал сетевых решений. LAN. −
1998. − №10.
2. ASN.1/C++. Application Programming Interface Part 1: Base Classes and Specific Interface/
NMF 040-1 − 1998. −Issue 1.0.
3. Divakara K. Udupa TMN: Telecommunications Management Network/ McGraw-Hill. −
1999. – 420 p.
4. EM Programming Concepts/Sun Microsystems. − 1996. Режим доступа :
[http://www.dkrz.de/~k202046/em/products/sem/Manuals/dev_guide/em_concepts.doc.html
18.01.01]
5. ETR 298. Methods for Testing and Specification (MTS); Specification of protocols and services; Handbook for SDL, ASN.1 and MSC development/ETSI Technical report. – September,1996. Режим доступа : [portal.etsi.org/edithelp/pdf/298__r1.pdf 5.09.01]
6. ETSI ETR 060. Signalling Protocols and Switching (SPS); Guidelines for using Abstract
Syntax Notation One (ASN.1) in telecommunication application protocols/ Second Edition. −
1995. Режим доступа : [portal.etsi.org/edithelp/pdf/060__r2.pdf 11.07.01]
7. EURESCOM Project P609. TMN Specification Support. Deliverable 4. TMN Guidelines 97.
Volume 1 of 7: Main part/For full publication. − 1997. Режим доступа
[www.eurescom.de/public/projects/ p600-series/P609/P609.HTM 15.03.01]
8. EURESCOM Project P609. TMN Specification Support. Deliverable 4. TMN Guidelines 97.
Volume 5 of 7: Annex D. Process Modelling for PNOs/ For full publication. − 1997. Режим
доступа [www.eurescom.de/public/projects/ p600-series/P609/P609.HTM 15.03.01]
9. Hasselmeyer P. A Methodology for Formalizing GDMO Behavior Descriptions. Information
Technology Transfer. − Office Darmstadt University of Technology Wilhelminenstr, Germany. Режим доступа : [http://citeseer.nj.nec.com/hasselmeyer99methodology.html
14.05.01]
10. ITU-T Recommendation X.691. Information technology − ASN.1 encoding rules: Specification of Packed Encoding Rules (PER) − 1995.
11. ITU-T Recommendation X.690. Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER). − 1994.
12. ITU−T Recommendation M.3100. Generic network information model. − 1995.
13. ITU−T Recommendation Z.105. SDL combined with ASN.1 (SDL/ASN.1) Режим доступа
[http://www.tdr.dk/public/SDL/litt.html 28.04.01]
14. I-ETS 300 293. Telecommunications Management Network (TMN). Generic managed objects. − 1996. Режим доступа : [http://pda.etsi.org/pda/home.asp?wki_id=873 1.02.01]
Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

15. ISO
8824
Encapsulations
specifications.
http://www.digest.org/html/gp2b1.htm#A1 4.05.01]

104
Режим

доступа

:

[

16. Layman's Guide to a Subset of ASN.1, BER, and DER An RSA Laboratories Technical Note
Режим доступа : [http://www.rsasecurity.com/rsalabs/pkcs/index.html 8.05.01 ]
17. Object
Identifiers.
Descriptions.
Режим
http://www.alvestrand.no/harald/objectid/ 28.04.01]

доступа

:

[

18. Pras A. Network Management Architectures. − CTIT Ph. D-thesis series No. 95-02. − Thesis
University of Twente, Enschede. - With ref. ISBN 90-365-0728-6. − 1995. Режим доступа :
[http://www.simpleweb.org/nm/research/results/publications/pras/thesis.html 17.10.01]
19. Sloman M (editor) and others. Network and Distributed Systems management. − Addison
Wesley. − 1994.
20. Williamson B. J. and Farrell C.A. Independent active program representation using ASN.1.
Режим доступа : [http://asn1.elibel.tm.fr/fr/biblio/ccr-9904-williamson.pdf 19.05.2001]

Глава 4. Версия 2.1

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

106

5. ОБЩИЙ ПРОТОКОЛ ИНФОРМАЦИИ УПРАВЛЕНИЯ CMIP
5.1 Элементы управления в модели ВОС
Эталонная семиуровневая модель взаимодействия открытых систем (ВОС),
предложенная Международной организацией по стандартизации (МОC), определяет
коммуникационные протоколы как обобщенные функции, требующиеся для успешной связи между программами прикладного уровня двух открытых систем.. Управление системой в рамках концепции ВОС можно рассматривать как определенное
взаимодействие между объектами с помощью коммуникационных протоколов для
обеспечения разнообразных функций и услуг управления.
Стандарты ВОС, в частности стандарт ISO 9595, включают описание услуг
управления, известное как «Элемент общей услуги информации управления»
(Common Management Information Services Element, CMISE) [6, 7]. В рамках объектно-ориентированного подхода CMISE – это прикладной элемент услуги (Application
Service Element, ASE), разработанный для поддержки управления системами.
Прикладной элемент услуги – это программный объект, который обеспечивает коммуникационные потребности различных приложений. Примеры реализаций
ASE включают, например, контроль связи между элементами службы управления
при обмене информацией, управление передачей файла, управление доступом, удаленное управление директориями. При реализации ASE предусматривается возможность его многократного использования несколькими прикладными программами.
Описание CMISE, как и любого стандарта ВОС, реализуется в терминах услуг (services), которые машина протоколов (protocol machine) обеспечивает пользователю, и в терминах форматов протокольных блоков данных (Protocol Data Units,
PDU), которыми обмениваются равноправные/одноуровневые, с точки зрения модели ВОС, прикладные задачи управления [9].
Услуги информации управления используются прикладными процессами для
обмена информацией и командами с целью управления системами. Существует два
типа таких услуг:
- услуги управления уведомлениями (a management notification service);
- услуги управления операциями (management operation service).
Общая услуга информации управления предоставляет дополнительные удобства по структурированию информации. В частности, здесь существуют такие возможности, как множественные ответы с целью подтверждения выполнения операции, которые взаимосвязаны (linked) с данными операциями с помощью параметров
идентификации (identification parameter). Операции выполняются на нескольких
управляемых объектах, которые выделяются по некоторым критериям.
Элементы, формирующие структуру управления ВОС и относящиеся к ASE:
- элемент услуги приложения управления системой (System Management
Application Service Element, SMASE);
- элемент общей услуги информации управления (Common Management
Information Service Element, CMISE);
- элемент услуги управления ассоциацией (Association Control Service
Element, ACSE);
- элемент услуги удаленной операции (Remote Operations Service Element,
ROSE);
- функция координации (co-ordination function).
Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

107

Хочется обратить внимание на источник [1], в котором ASE рассматривается в
рамках описания подсистемы пользователя интеллектуальной сети (INAP) системы
ОКС №7.
ACSE используется, чтобы установить прикладные ассоциативные связи, или
ассоциации (application associations) между программой-менеджером и программойагентом. Во время установления ассоциативной связи различные ASE могут обмениваться информацией, которая инициализирует процесс организации связи с использованием ASCE. Приложения управления поддерживают правила, которые необходимы для координации информации, принадлежащей различным ASE. Эти правила
записываются с помощью параметров услуг пользователя ASCE. Содержание прикладного уровня, требования уровня представления и сеансового уровня передаются
с помощью параметров услуги A-ASSOCIATE, которая обсуждается ниже.
ROSE используется для оформления информационных запросов и передач, в
частности удаленного вызова процедур (Remote Procedure Calls, RPC), используемых
в разных системах (см. рис. 5.1).
Далее рассматриваются элементы и услуги модели ВОС, имеющие отношение к обмену информацией управления. Внутренняя логика процесса управления не
затрагивается [6].
SM ASE

CM ISE

ACSE

Область
API интерфейсов

ROSE

1 - 6 уровни модели ВОС

Рис. 5.1. Элементы управления в модели ВОС
В CMISE имеются два вида функций управления системами для сетей, удовлетворяющих стандартам ВОС. Это общие услуги информации управления (Common
Management Information Services, CMIS) и общий протокол информации управления
(Common Management Information Protocol, CMIP), определяемый стандартом ISO
9696.
CMIS определяет функции контроля и управления сетью и обеспечивает интерфейс пользователя. CMIP используется для поддержки обмена информацией
управления, чтобы эксплуатировать сеть связи, осуществлять управление и обеспечивать нормальный режим функционирования сети. CMIS и CMIP являются частью
большого и сложного набора стандартов для управления системами на основе модели ВОС. При этом CMIP обеспечивает взаимодействие открытых систем на прикладном уровне.
Протокол обмена информацией основан на парадигме ответа на запрос, в соответствии с которой программа-менеджер инициирует операции управления на одном или большем количестве управляемых объектов. Услуги и протоколы определе-

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

108

ны в CMISE посредством:
- описания различных операций, которые осуществляются системой управления на объектах управления;
- сообщений/уведомлений, которые выдаются управляемыми объектами
управляющей системе.
Такая архитектура требует, чтобы была определена структура управляемого
объекта. Как уже отмечалось, управляемый объект является абстрактным представлением управляемого физического ресурса и содержит информацию, требуемую для
успешного осуществления процесса управления.
При каждом информационном обмене программа−менеджер посылает программе−агенту запрос на выполнение операции управления (см. рис. 5.2).
Рис. 5.2. Управление открытыми системами в рамках модели «агент-менеджер»
Операции управления подразумевают наличие протокола информационного
обмена для создания, удаления, чтения данных и изменения информация управления.
Термин «информация управления» (management information) используется здесь для
описания свойств объектов управления. В дополнение к вышеупомянутым операциям, CMISE поддерживает сообщения, которые генерируются на объектах управления
и описывают происшедшие на объекте события [3].
Управляю щий
процесс
(программаменедж ер)

П ередача команд и
сообщ ений

Управляемы й
процесс
(программаагент)

Управляем ы
е объекты

Граница уровня CM IS
M IB

СM ISE

CM IP

СM ISE

Примерами различных классов управляемых объектов являются элемент сети
(NE), файл журналирования (logfile) данных об управлении и отдельная журнальная
запись (logRecord) о каком−то сетевом событии. Управляемый ресурс может иметь
дополнительную информацию для осуществления эффективного управления. Если
объектом управления является аппаратная часть элемента сети (абонентский комплект), то такие управляемые ресурсы, как процесс приёма и трансляции цифр набора номера или тестирование абонентской линии в процессе установления соединения, могут не рассматриваться в CMISE в силу того, что в данном случае они не
представляют интереса для обмена информацией между приложениями. Все перечисленные функции осуществляются на уровне программ технологического управления коммутационных узлов и относятся к уровню, которые в главе 3 был назван
уровнем управления оборудованием (control plane).
CMISE рассматривает базовые операции управления как общие для различных
функциональных областей. Первоначально CMISE предназначалось для управления
протоколами ВОС. В телекоммуникационной индустрии это один из основополагающих стандартов сетевого управления. Об этом свидетельствуют спецификации
правительственного сетевого протокола управления (Goverment Network Management
Protocol, GNMP) из NIST и спецификации OMNIPoint 1 организации «Форум управ-

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

109

ления сетью» (Network Management Forum, NMF) и их партнеров по стандартам промышленного управления.
В частности, использование CMISE для ISDN определено в рекомендациях
МСЭ-Т для подключения интерфейса «сеть-пользователь» (User−Network Interface,
UNI) предполагаемого оборудования абонента. Для реализации этого интерфейса услуги и протоколы CMISE используется с ISDN−протоколами Q.931 и Q.932 без
транспортного, сеансового уровней и уровня представления, требуемых в модели
ВОС.
CMIP основан на базах данных управления (Management Information Base,
MIB), т.е. на совокупности управляемых объектов. Эти объекты имеют атрибуты, обладают некоторым поведением, могут быть созданы и удалены и инициируют в прикладной программе специфические действия, которые запрашиваются менеджером.
Поведение объекта обусловлено ресурсом управления, который этот объект
представляет. Например, функционирование терминального окончания (termination
point) соединительной линии или канала связи может зависеть от функционирования
(поведения) других компонентов системы, например системы синхронизации или
типа физической среды переноса сигнала электросвязи.
Как уже говорилось, атрибуты объекта управления описывают состояние и
условие поведения данного объекта. Рассматривая в качестве примера точку окончания (например, сетевое окончание в ISDN), можно сказать, что атрибуты включают
ссылки на другие объекты, с которыми взаимодействует точка окончания. Например,
допустимы ссылки на окончания LT.
Аналогично действия (actions) рассматриваются здесь как услуги, которые
объект может обеспечивать при запросе системы управления. Шаблоны (templates)
для описания поведения/функционирования объектов управления определены в TMN
средствами GDMO и ASN.1. Поскольку объекты идентифицированы программойагентом или программой-менеджером системы управления, объекты управления становятся также однозначно идентифицированными.

5.2 Функциональные модули и услуги CMIS
5.2.1

Описание функциональных модулей CMIS

Согласно модели ВОС, взаимодействие между прикладными задачами управления (приложения управления) осуществляется выше уровня протокола CMIP – на
уровне CMIS. CMIS включает все услуги, доступные в ходе управления, а также интерфейс с пользователем.
CMIS поддерживают механизм выдачи подтверждений о выполнении операции «Запрос» (request), а некоторые услуги – неподтверждаемые операции (т.е. операции, выполнение которых не требует подтверждения).
Операции запроса с подтверждением (сonfirmed request operations) всегда
требуют ответа, независимо от успеха или отказа в совершении операции. Операции
запроса, не требующие подтверждения (unconfirmed request operations), не получают
подтверждения о выполнении.
Услуги с подтверждением требуют, чтобы программа-агент, которая выполняет операции на управляемом объекте, послала с помощью CMIS управляющей системе «квитанцию» – подтверждение (receipt, responce) со сведениями о том, закончилась ли операция управления успешно или произошла ошибка. Услуги без подтверждения такого механизма не имеют.
Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

110

CMIS определяют услуги, которые могут поддерживать программыменеджеры и программы-агенты, а также набор функциональных модулей, которые
собственно и определяют эти услуги. Функциональные модули предназначены для
поддержки примитивов, или параметров услуг. Когда менеджер и агент устанавливают связь друг с другом, они «договариваются» о том, какие услуги (что определяется как раз функциональными программными модулями) могут использоваться при
взаимодействии между ними. Фактически функциональный модуль является компонентом прикладной программы управления.
В CMIS [4] определены следующие функциональные модули:
1. Функциональный модуль MultipleObjectSelection относится к услугам, которые определяют область опрашиваемых (scoping) управляемых объектов. Это механизм, который позволяет направлять одиночный запрос нескольким управляемым
объектам. Распространение запроса к этим объектам закончится тем, что каждый
управляемый объект сгенерирует ответ (см. ниже описание MultipleReply). Поддержка модуля MultipleObjectSelection не обязательна для программ−менеджеров и программ−агентов ВОС. Если менеджер или агент ВОС
поддерживает
MultipleObjectSelection, менеджер или агент должен также поддерживать
MultipleReply.
2. Функциональный модуль MultipleReply осуществляет генерацию ответов на
запрос. Запрос, с помощью которого осуществляется опрос объектов (см.
MultipleObjectSelection) может завершиться многократными ответами. С помощью
специального идентификатора функциональный модуль MultipleReply определяет,
является или нет данный ответ последним. Поддержка MultipleReply необязательна
для менеджеров и агентов ВОС. Если менеджер или агент поддерживает
MultipleReply,
менеджер
или
агент
должен
также
поддерживать
MultipleObjectSelection.
3. Функциональный модуль filter (фильтр) относится к запросам CMIS, которые инициируют тест на управляемом объекте. Этот тест проводится перед выполнением запроса. Если тест завершается успешно, запрос выполняется. Если тест не
проходит, то запрос не выполняется. Фильтр почти всегда используется в запросе,
который использует выделение области опрашиваемых объектов. Поддержка фильтра не обязательна для менеджеров и агентов ВОС.
4. Функциональный модуль kernel (ядро) осуществляет поддержку для следующих операций CMIS: M-Event-Report; M-Get, M-Set, M-Action, M-Create и MDelete (раздел 5.3). Все менеджеры и агенты ВОС поддерживают этот модуль.
5. Функциональный модуль ConfirmedCancelGet определяет поддержку для
услуги M-Cancel-Get. Поддержка этого модуля для менеджеров и агентов ВОС необязательна.
6. Поддержка функционального модуля extendedService и соответствующих
прикладных программ описана в Рек. МСЭ-Т X.710 и в Рек. ISO 9595. Требуемую
информацию можно получить в спецификации коммуникационной модели ВОС, которая изложена в Рек. МСЭ-Т X.200, X.210 и X.216.
CMIS предусматривает использование операций CMISE. С их помощью реализуются разнообразные услуги, которые подразделяются на три категории (рис.
5.3):
1. Услуги управления ассоциацией (Management Association Services, MAS) это услуги, которые обеспечивают обмен информацией между управляемым и
Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

111

управляющим объектами, реализуются с помощью трёх операций.
2. Услуга передачи уведомлений в процессе управления (Management
Notification Service, MNS) - это услуга, которая используется, чтобы передать прикладной программе уведомление о получении информации по управлению.
3. Услуги управления операциями (Management Operation Services, MOS) состоят из шести операций, с помощью которых оказываются услуги по передаче и обработке информации, соответствующей программным приложениям управления.

Приложения управления
(программы -менеджеры и программы -агенты )

Услуги организации
ассоциации

Услуги передачи
уведом лений

Услуги управления
операциями

CMISE

CMIP

ACSE

RO SE

Рис. 5.3 Взаимодействие между CMIP, CMIS, CMISE
Итак, как уже отмечалось, внутри MAS имеются три услуги (рис. 5.4):
услуга M-Associate позволяет инициализировать соединение с равной по
уровню (с точки зрения модели ВОС) функцией CMISE другой открытой
системы;
- услуга M-Release разрывает соединение между равными, с точки зрения
ВОС, функциями CMISE;
- услуга M-Abort используется, когда соединение между двумя пользователями разрывается нештатно.

-

Элемент прикладной услуги управления системой
SM ASE

M-Associate
M-Release
M-Abort

M-EVENT-REPO RT
M-G ET, M-SET,
M-ACTIO N,M-CREATE,
M-DELETE, M-CANCEL-G ET

CMISE API

Элемент услуги общего управления информацией
CM ISE

Рис. 5.4 Услуги MAS и MOS

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

112

MNS обеспечивают необходимые ресурсы для управляемых объектов (например, пропускную способность каналов), чтобы послать сообщение о сетевых событиях на станцию управления. Это сообщение обрабатывается посредством услуги MEVENT-REPORT.
В документе ISO/IEC 9595 для CMIS определены шесть услуг MOS: M-GET,
M-SET,
M-CREATE,
M-DELETE,
M-ACTION,
M-EVENT-REPORT,
MCANCEL−GET. При этом услуги M-SET, M-ACTION и M-EVENT-REPORT могут
исполняться в режиме с подтверждением или в режиме без подтверждения.
Чтобы выполнить операции управления, пользователи должны сначала установить связь с соответствующим приложением управления. Здесь подразумевается
не только физическое соединение, но в первую очередь возможность обмена информацией между прикладными программами управления. ВОС определяет, что функции управления одного и того же уровня могут стать доступными верхним уровням с
помощью активизации элемента услуги службы управления ассоциацией (ACSE).
ACSE оказывает две услуги пользователям CMISE:
1. Установление связи (ассоциации) с прикладной программой/приложением
управления, будь то менеджер или агент. Эта функция используется, чтобы использовать элементарные услуги CMISE.
2. Во время установления связи (ассоциации) между прикладными программами управления менеджеры и агенты «договариваются» о том, какие особенности
CMISE будут использоваться при этом соединении.
Перед тем как будут приведены детальные описания операций MOS, следует
отметить следующее. На практике еще до использования операций MOS необходимо
указать, в каких терминах определены свойства объектов управления (например, с
помощью модифицируемых или немодифицируемых атрибутов); необходимо отметить, как генерируются сообщения о событиях и как выполняются действия на
управляемых объектах. Следует иметь в виду, что некоторые из операций MOS могут использоваться для индивидуального объекта или для множества объектов.
Далее услуги MOS рассматриваются более подробно [5,10].
5.2.2

Описание услуг MOS

Услуга M-GET используется, чтобы найти, восстановить или собрать информацию
для управления объектами. Эта услуга с подтверждением выполнения дает возможность данной открытой системе восстановить или найти значение атрибута/атрибутов одного или множества управляемых объектов, находящихся в другой
открытой системе. Обязательные параметры, связанные с запросом MOS, – последовательный номер запроса и наименование управляемого объекта.
Запрос услуги M-GET может включать защищенную часть, чтобы подтвердить правомерность запроса, и идентификаторы атрибутов, значения которых должны быть найдены или восстановлены. Если атрибуты не определены, это означает,
что запрошены значения всех атрибутов управляемого объекта. Если производится
запрос к множеству объектов, то по каждому объекту выдается один ответ на запрос.
Последовательный номер начального запроса в ответе используется в случае
многократных ответов на запрос. Поэтому в ответе часто присутствует ссылка на
последовательный номер запроса как на параметр. Этот параметр называется связанным идентификатором (linked-ID). Если операция, активизированная M-GET, выполнена успешно, то процедура передачи ответов от множества объектов завершается
соответствующим указанием в последнем ответе. Если операция не выполнена или в
Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

113

процессе выполнения произошла ошибка (частичное выполнение можно рассматривать как ошибку), то запрос снимается, при этом выдаётся сообщение об ошибке. В
случае частичного выполнения действий при вызове услуги M-GET поступившие ответы содержат как информацию об ошибке, так и значения атрибутов, которые всетаки удалось получить.
Услуга M-CANCEL-GET используется, чтобы отменить M-GET. Эта услуга
предоставляется с выдачей подтверждения, чтобы отменить M-GET, если не получен
ответ. Отмена M-GET может быть необходима, например, если для запроса было выбрано слишком много объектов и приложение управления не может обработать ответы от многих объектов. Также отмену M-GET можно использовать в случае, когда
запрос выполняется слишком долго. Если операция M-GET была завершена прежде,
чем получена M-CANCEL-GET, то выдается сообщение об ошибке.
Если отмена услуги произошла успешно, то для M-CANCEL-GET выдается
положительное подтверждение, а для предыдущей услуги M-GET – сообщение об
ошибке. При формировании M-CANCEL-GET обязательными параметрами являются последовательный номер данного запроса и последовательный номер запроса, который будет отменен.
Услуга M-SET используется, чтобы изменить/модифицировать существующую информацию управления Эта услуга используется приложением управления,
чтобы запросить модифицированные значения атрибута или атрибутов одних или
нескольких управляемых объектов в другой открытой системе. Обязательными параметрами являются последовательный номер запроса услуги, обозначение объекта
управления и оператор модификации, который описывает, как модифицируются данные управляемого объекта.
Использование оператора модификации позволяет изменить значения атрибута объекта управления, добавить новое значение или удалить существующие значения для набора атрибутов. В последнем случае атрибутам присваиваются значения
по умолчанию, определенные для данного объекта управления. Множество допустимых значений, зафиксированное в множестве атрибутов, можно рассматривать как
математическое множество, особенно когда выполняется операция добавления. Новое значение атрибута не будет добавлено, если оно уже существует, а сообщение об
ошибке при этом не выдается.
Если при оказании услуги M-SET выбирается несколько объектов, то все
процедуры подобны тому, что было описано для M-GET. Однако в отличие от MGET, услуга M-SET может работать как с подтверждением, так и без подтверждения
о ее выполнении. Обработка ответов от множества управляемых объектов и завершение запроса применяется только при режиме с подтверждением. В режиме без
подтверждения система управления может определять только результаты запроса
(успешный или неуспешный) при изменении значений атрибутов.
Услуги M-ACTION используется для информирования равной (с точки зрения ВОС) системы о выполнении определенного действия на управляемом объекте.
Эта услуга позволяет открытой системе направить запрос в другую открытую систему на выполнение определенных действий на одном или нескольких объектах
управления.
Тип действия ACTION должен входить в состав описания управляемого объекта и относится к допустимым действиям над объектом. Для различных классов
управляемых объектов существуют специфические действия и, соответственно, специфические функции управления. Поэтому подробности, связанные с выполнением
действий (например, предварительные условия осуществления действий), в CMIS не
определяются. Обязательными параметрами являются следующие: последователь-

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

114

ный номер запроса, обозначение объекта управления и тип действия. Необязательные параметры включают специфическую информацию для данного типа действия и
конфиденциальную информацию управления (security control information).
Оказание услуги M-ACTION при выполнении действий на нескольких объектах аналогичны ранее определенным для M-SET. Руководство по выбору модели
управления объектом между операцией SET для атрибутов и операцией ACTION для
управления поведением находится в Рек. ISO/IEC 10165-1 Management Information
Model (Информационная модель управления). Например, услуга M-ACTION используется, когда информация при запросе не входит в состав атрибутов объекта или когда требуется определить сложные операции типа «установить и протестировать».
Услуга M-CREATE используется, чтобы создать новый управляемый объект.
Необходимость в данной услуге и соответствующей операции возникает при подключении к сети нового устройства. С помощью данной услуги можно сообщить
другим приложениям того же уровня ВОС о появлении на сети нового объекта. В отличие от других услуг, в ответ на запрос M-CREATE может быть создан только один
объект управления. Здесь могут использоваться различные методы создания имени
нового управляемого объекта и присвоения значений атрибутов. Новый управляемый
объект может быть создан как копия существующего объекта, но с другим именем.
Чтобы отменить скопированные значения атрибутов, могут быть запрошены значения для атрибутов при создании копии нового объекта. Имя для вновь созданного
объекта может быть назначено одним из следующих способов:
- явное имя представляет собой уникальный идентификатор нового объекта
на основании имени вышестоящего (старшего) объекта. Как правило, имена
объекты управления получают, используя отношение «наследования»
(containment). Имя объекта получается путем «спуска» вдоль дерева наследования, начиная от корневого объекта. Другими словами, имя управляемого объекта включает имя старшего объекта. При этом имя нового управляемого объекта управления уникально;
- имя полностью назначается системой, создающей объект, но при этом подчиняющееся ограничениям, определенным для объектов в силу наличия
старшего объекта и соответственно его имени.
Определение значений атрибутов вновь создаваемого объекта управления зависит от значений, которые указаны в запросе, а также от того, имеются или нет значения по умолчанию или начальные значения. Соответствующие правила содержатся
в Рек. ISO/IEC 10165-1. Если нельзя присвоить значения всем требуемым атрибутам,
то операция M-CREATE будет неудачна, и будет выдано сообщение об ошибке. Если операция M-CREATE успешно завершена, то имя нового объекта управления будет включено в ответ на запрос M-CREATE, если это не предусматривается автоматически. Дополнительно в ответ могут включаться идентификаторы и значения всех
атрибутов, назначенных данному объекту управления.
Услуга M-DELETE по характеру действия противоположна операции MCREATE. Эта услуга используется, чтобы направить запрос в другую открытую систему на удаление одного или нескольких управляемых объектов. Обязательные параметры в запросе: последовательный номер запроса и обозначение управляемого
объекта. Если удаляется множество объектов, то подтверждения об удалении генерируются отдельно для каждого объекта. Чтобы поддержать целостность набора
имен при удалении одного или нескольких объектов и с учетом того, что управляемые объекты расположены в древовидной структуре, удаление объекта может быть
выполнено одним из двух способов :
- удаление старшего объекта через удаление всех нижестоящих объектов;

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

115

-

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

5.3

Общий протокол информации управления CMIP

Протокол CMIP используется СMISE для сбора, обмена и изменения информации об управляемых объектах. Это позволяет осуществлять управление элементами всех уровней модели ВОС. CMIP – это протокол, у которого нет «неинтеллектуальных» программ-агентов, напротив, агенты CMIP на объектах управления более
интеллектуальны, чем их аналоги в других стандартах сетевого управления.
CMIP формирует протокольные блоки данных (PDU) и осуществляет обмен
PDU между одноуровневыми услугами CMISE, чтобы реализовать сервисы CMIS.
CMIP следует таким же правилам обмена PDU, как и другие протоколы ВОС. В дополнение к ACSE, о котором говорилось ранее, этот обмен зависит от ROSE. CMIP
используется для обеспечения услуг управления операциями и услуг передачи уведомлений CMISE (рис. 5.5). Можно сказать, что CMISE, ASCE и ROSE представляют
собой стек CMIP (рис. 5.6).
Каждая услуга CMISE определяет несколько CMIS-примитивов (элементарных услуг), которые отображаются с помощью сообщений CMIP в виде PDU. Протокол CMIS, по сути, определяет интерфейс с пользователем услуг CMISE. Полный
список сообщений и форматов сообщения CMIP приведён в Рек. МСЭ-Т X.710 (аналог Рек. ISO/IEC 9595) и Рек.X.711 (аналог Рек. ISO/IEC 9596-1).
Важное значение в понимании функционирования CMIP имеет понятие протокольной машины CMIP (Common Management Information Protocol Machine,
CMIPM). Данная протокольная машина является логическим представлением основных функций CMIP. На стороне программы−менеджера, которая выдаёт управляющие команды, протокольная машина принимает запросы CMIS на предоставление
CM ISE-прикладные задачи управления пользователя
услуг управления системой. На основании поступивших запросов CMIS в
протокольной машине CMIP инициализируются те или иные примитивы. В результате протокольная машина CMIP выдаётСMIS
ответы
(подтверждения) на запросы примитиPDU
вов, а также генерирует протокольные блоки данных CMIP, которые передаются на
M -GET
M -DELETE
M -CANCEL-G ET
M -EVENT-REPORT
нижестоящий уровень (рис. 5.7).
M -SET

M -ACTION

M -CREATE

СMIP PDU
m -Get

m -Set

m -Delete

m -SetConfirm ed

m -Action
m -ActionConfirm ed

m -Create

m -Cancel-GetConfirm ed

m -EventReport

m -EventReportConfirm ed

m -Linked-Reply

Глава 5. Версия 2.0

Презентационный уровень

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

116

Рис. 5.5 Взаимосвязь протокольных блоков CMIS и CMIP

Рис. 5.6 Стек протокола CMIP − ACSE и ROSE

Элемент услуги общего управления информацией
CM ISE
A-Associate
A-Release
A-Abort

RO-Invoke, RO-Reject,
RO-Result, RO-Error

ACSE/ROSE API
Элемент услуги
управления ассоциацией
ACSE

P-CONNECT
P-RELEASE
P-ABORT

Элемент услуги
удалённой операции
ROSE

P-DATA

Презентационный уровень

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

117

На стороне программы−агента, т.е. при выполнении управляющей команды
CMIPM принимает с нижестоящих уровней корректные PDU и передаёт информацию по требуемым услугам управления на уровень CMISE. Если PDU не корректен,
т.е не поддерживает требуемых средств подтверждения выполнения запроса на услугу или самой услуги, то такой PDU отбрасывается, о чём выдаётся соответствующее
уведомление. Следует отметить, что CMIPM осуществляет только PDU, не затрагивая вопроса о том, что происходит с данными на уровне CMIS или как инициализируются услуги CMIS со стороны пользователя.
CMISE может запрашивать следующие услуги ASCE : A-ASSOCIATE, ARELEASE, A-ABORT, и A-P-ABORT.
Пользователь услуг
СMISE
Запрос
примитива CMIS

CMIP
PDU

Ответ на запрос
примитива CMIS

Протокольная машина
CMIP
CMIP (CMIPM)

Передача
CMIP PDU

Ответ на передачу
CMIP PDU

ROSE

Рис. 5.7 Протокольная машина CMIPM
Здесь и далее согласно Рек. МСЭ−Т X.638 перед наименованием услуг
указываются специальные буквенные идентификаторы:
- R указывает на принадлежность услуги или операции к ROSE согласно Рек.
ISO/IEC 9072-4;
- A указывает на принадлежность услуги или операции к ACSE согласно Рек.
МСЭ−Т X.247 | ISO/IEC 8650-2
- P указывает на принадлежность услуги или информации к уровню представления
согласно Рек. МСЭ−Т X.246 | ISO/IEC 8823-2;
- S указывает на принадлежность услуги или информации к сеансовому уровню
согласно Рек. МСЭ−Т ITU-T Rec. X.245 | ISO/IEC 8327-2.
Система с подтверждением должна использовать по крайней мере один из
приведенных сервисов. При этом система может выполнять функции как управляемой системы, так и управляющей.
В процессе обмена информацией услуга A-ASSOCIATE и соответствующие
процедуры используются для установления взаимодействия между двумя приложениями. Услуга A-RELEASE используется в случае, когда пользователь, пославший
запрос, не согласен с ранее организованным взаимодействием между приложениями.
Причём в случае прекращения ранее установленной связи между приложениями не
происходит потери информации.
Услуга A-ABORT используется в случае ошибках при передаче информации
или при аварии. При использовании услуги A-ABORT с целью аварийного обрыва
связи между двумя приложениями существует потенциальная возможность потери
Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

118

информации. Тем не менее сервис A-ABORT используется в случае, когда обнаружено нарушение коммуникационного протокола или когда связь между приложениями еще не установлена.
Сервис A-P-ABORT используется для обнаружения аварийного прекращения
операции на уровне представления процедуры управления с возможной потерей информации при передаче.
Существует 4 типа связей, которые могут быть установлены между приложениями управления:
1. Тип Event, который определяется операцией M-EVENT-REPORT; эта операция осуществляется управляемой системой.
2. Тип Event/Monitor − соответствует типу Event за исключением того, что
управляющая система может выдавать запрос на выполнение операции MGET и получать ответ на запрос.
3. Тип Monitor/Control − в данном случае управляющая система может выдавать запросы на выполнение M-GET, M-SET, M-CREATE, M-DELETE и
M-ACTION. При этом могут быть недоступны сообщения о событиях
(event reporting) на управляемом объекте.
4. Тип Full Mgr/Agent, при котором поддерживаются все операции CMIS.
Следует отметить, что управляемая система (управляемый объект) может
только запросить связь типа Event. Фактически это означает, что связь организуется в
случае наличия сообщения о каком-то событии на объекте управления, если такая
связь не была организована ранее. Управляющая система может запрашивать связь
любого типа.
Управляемая система или объект может «договориться» с управляющей системой о переходе от типа связи Full к типу Monitor/Control, Event/Monitor или Event
с помощью процедуры возврата нового значения в ответе на запрос A-ASSOCIATE.
Для поддержки протокола CMIP также используются сервисы ROSE: ROINVOKE, RO-RESULT, RO-ERROR и RO-REJECT. Сервисы ROSE сведены в таблицу 5.1.
Таблица 5.1
Сервисы ROSE

Определение сервиса ROSE

RO-INVOKE

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

RO-RESULT
RO-ERROR
RO-REJECT-U
RO-REJECT-T

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

119

В качестве примера действия CMIS рассмотрим установление IP-адреса компьютерного устройства. Для этого система управления выполняет операцию M-GET,
что приводит к появлению соответствующей команды CMIP для установления IPадреса компьютерного устройства. Во всех случаях именно CMISE вызывает команду CMIP, чтобы получить требуемую информацию (рис. 5.8)
Пользователь услуг
CM ISE - инициатор
запроса
Запрос
M-G ET

Пользователь услуг
CMISE - получатель
запроса
О твет на
M-G ET

Уведомление
M-G ET

Инициализация
CM IPM
Запрос
RO -INVO KE

Индикация
появления
M-G ET

Реакция CMIPM на
запрос

Индикация
RO -RESULT

Запрос
RO -RESULT

RO SE

Индикация
появления
RO -INVO KE

RO SE

Запрос M-G et

M -G et
(RO-RESULT )

Индикация
появления M -G et
О твет на M-G et

Время

M -G et
(RO-Invoke)

Уведомление
M-Get

Рис. 5.8. Оказание услуги M−GET с помощью ROSE
В результате именно CMIP, а не CMISE выдает требуемые PDU. При получении ответа от получателя запроса именно CMIP транслирует этот ответ, а CMISE сообщает результат пользователю.
В заключение рассмотрим функционирование процедуры GET, которая
позволяет предоставить пользователю CMISE услугу M−GET.
Запрос процедуры GET осуществляется с помощью специального примитива
запроса на предоставление услуги M−GET, после получения которого протокольная
машина осуществит следующие операции :
- cформирует специальный протокольный блок (APDU) для запроса операции
M−GET;
- передаст APDU на удалённый объект с использованием процедуры RO-INVOKE.
На удалённом объекте, который принимает запрос на выполнение операции
M−GET в виде соответствующего APDU, протокольная машина CMIPM в случае,
если APDU корректен, выдает пользователю услуг CMISE примитив индикации
M−GET, который указывает принимающей стороне на появления запроса на оказание услуги M−GET. Если поступивший APDU некорректен, то протокольная машина на приёме сформирует APDU с уведомлением об ошибке и направит этот APDU
инициатору (передатчику) запроса услуги M−GET с помощью процедуры ROREJECT-U.
Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

120

При формировании ответа на запрос M−GET протокольная машина получателя запроса (т.е. на приёме) выполнит следующие операции:
- примет ответы на запрос M−GET, которые поступают от получателя запросапользователя услуг CMISE; эти ответы могут содержать параметры Linked−ID,
если даётся несколько ответов на множество запросов M−GET;
- сформирует APDU, подтверждающий выполнение операции M−GET;
- операция M−GET передаст сформированный APDU с результатами операции
инициатору запроса с помощью процедуры RO−RESULT; в случае ошибки передаётся RO−ERROR.
При получении APDU, соответствующего операции M−GET, протокольная
машина инициатора запроса выполнит следующие операции:
- если APDU корректен, является последним ответом или включает связанный
идентификатор linked−ID, то выдаётся подтверждение выполнения M−GET пользователю услуг CMISE;
- если полученный APDU некорректен, то формируется специальный APDU, содержащий уведомление об ошибке; этот APDU передаётся получателю запроса с
помощью RO-REJECT-U.
Итак, протокол CMIP осуществляет передачу информации управления между
различными открытыми системами. Приведённое описание показывает сложность
данного протокола. Тем не менее, доступ к CMIP может быть реализован достаточно
простыми средствами, которые рассматриваются в следующем разделе.

5.4

Организация интерфейса пользователя CMIP с помощью языка Tcl

Рассматриваемые ниже команды, записанные с помощью командного языка
Tcl, обеспечивают доступ пользователя к возможностям и функциям CMIP, дают
возможность взаимодействовать с программой-агентом и в итоге получить доступ к
услугам CMIS [2, 8].
Каждая команда начинается с обозначения cmip. Это означает, что речь идет о
конфигурации объектов CMIP, т.е. программы-агента, которая взаимодействует с
объектом управления.
Язык программирования Tcl является текстовым языком с достаточно простым синтаксисом. Этот язык предназначен прежде всего для подачи команд интерактивным приложениям, в том числе приложениям сетевого управления. Программные библиотеки Tcl можно встраивать в прикладные программы, написанные
на других языках программирования. Библиотека Tcl состоит из анализатора языка
Tcl, подпрограмм, реализующих встроенные команды, и процедур, которые
позволяют расширять возможности Tcl. Применение программ, написанных с помощью Tcl, осуществляется в режиме интерпретатора, который реализован на языке
программирования Си. Существуют версии Tcl для различных операционных систем
и аппаратных платформ, что позволяет считать его достаточно мобильным программным средством. Одним из достоинств языка Tcl является то, что он позволяет
определять новые команды. В настоящее время язык Tcl и разработка новых версий
данного языка поддерживается компанией SUN Microsystems.

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

121

Команда языка Tcl имеет определённый формат:
<имя команды> <аргументы команды>? <опция команды>?;
где:
- имя команды отделяется от аргумента пробелом, в строку могут записываться
несколько команд, разделяемые точкой с запятой;
- знак ? является разделителем и указывает на аргументы или опции (см. ниже),
значение которых будет задано или вычислено, если это необходимо, при выполнении команды. Если ? не указан то, как правило, команда после выполнения выдаст 0 или 1 или весь требуемый список в зависимости от успеха или неудачи
требуемой операции.
Далее согласно [8] приводятся некоторые команды Tcl для организации доступа пользователя SMISE к услугам CMIP. Синтаксис предлагаемых команд зависит
от версии Tcl и применяемого интерпретатора Tcl.
Команды Tcl
Команда cmip connect устанавливает связь пользователя с программойагентом, которая функционирует на управляемом объекте. После ввода и выполнения этой команды появляется возможность активизировать специфические функции
агента.
Команда cmip wait блокирует систему управления, пока не будут обработаны
все запросы для всех установленных связей с помощью протокола CMIP. В период
ожидания ответов от управляемых объектов обрабатывается только информация о
событиях, которые в дальнейшем могут вызвать непредсказуемые эффекты на сети.
По команде cmip info формируется список всех существующих cmip−связей,
которые были созданы по команде cmip connect.
Команды ассоциации сmip
cmip# get class instance ? options ?
Команда cmip# get обеспечивает получение информации по управлению для связи,
установленной cmip connect. Аргументы class (класс) и instance (пример) определяют основной объект управления, данные о котором будут получены, если не произойдет изменений согласно следующих опций (options):
-scope scope ? -atomic?
Аргумент scope устанавливает область запроса. Если указан -atomic, это сообщает
программе-агенту о том, что запрос может выполнен только на всем множестве объектов управления, указанных scope .
-filter filter
Опция filter устанавливает фильтр, т.е. условие отбора для множества управляемых
объектов, которые относятся к области запроса.
-attributes attributes
Опция attributes позволяет формировать список, содержащий дополнительно запрашиваемые атрибуты. Если опция не указана, то по умолчанию выводятся все атрибуты объектов управления. Каждый элемент списка атрибутов может сам быть списком, но для поиска используется атрибут во главе списка.
cmip# set class instance attributes ?options ?
Команда cmip# set устанавливает определенные данные управления в программеагенте. Аргументы class (класс) и instance (пример) определяют основной объект

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

122

управления, для которого будут установлены некоторые значения атрибутов. Аргумент attributes (атрибуты) представляет собой список; элементы этого списка сами
являются списком, который состоит из трех составляющих: типы атрибутов, значения атрибута и признак операции модификации (modify-operation). Возможные операции модификации − замена (replace), добавление значения (addValue), удаление
значения (removeValue) и установка значения по умолчанию (setToDefault). Если тип
операции модификации не указан, то используется операция замены.
Среди доступных опций следует выделить опцию
-nonconfirmed
Эта опция устанавливает, что set становится услугой без подтверждения. Если опция
не установлена, то по умолчанию set является услугой с подтверждением.
cmip# action class instance action ?options ?
Команда cmip# action позволяет выполнить действие на программе-агенте. Аргументы class (класс) и instance (пример) определяют данные объекта управления, на котором будет выполняться действие. Действия может корректироваться с учетом опций
−scope и −filter. Действие представляет собой список, содержащий тип действий и
необязательные значения, характеризующие само действие.
cmip# create class ? options ?
Команда cmip# create cоздаёт управляемый объект для данного агента.
Доступные опции для создания объекта управления:
-instance instance | -superior superiorInst
Значение опции instance определяет имя экземпляра объекта управления, т.е. объекта
управления, который не является старшим в дереве наследований (см. раздел 5.3). В
противоположность instance, значение опции superiorInst определяет объект, который является старшим в дереве наследований.
-reference referenceInst
Значение опции referenceInst определяет ссылку на созданный экземпляр объекта
управления, который будет использоваться для копирования начальных значений атрибутов объекта.
-attributes attributes
Значение опции attributes определяет начальные значения атрибута списка; этот список включает пары тип атрибута - значение атрибута.
cmip# delete class instance ?options ?
Команда cmip# delete удаляет управляемый объект, который используется данным
агентом. Класс и образец определяют основной управляемый объект, который в результате будет удален, если иное не указано в опциях.
cmip# release
Команда cmip# release прекращает связь с управляемым объектом по принципу
разъединения, т.е. предоставляет безаварийный способ прервать связь с управляемым объектом.
cmip# abort
Команда cmip# abort используется в случае аварийного прекращения работы, немедленно прерывает связь с объектом управления по принципу внезапного разрыва соединения.
Как следует из описания услуг и команд, каждая программа−менеджер или

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

123

программа-агент является по-своему «интеллектуальной». Они могут на равных правах создавать экземпляры объектов управления одного итого же уровня модели ВОС,
т.е. нет «главного» менеджера. Другое дело, что из «интеллектуальности» агентов
CMIP (при сравнении с SNMP-агентами) следует ответственность агентов за сбор
информации на основании запросов.
Теоретически CMIS/CMIP обеспечивает намного более мощные средства
управления, чем коммерчески более успешный SNMP. Стандарты CMIS/CMIP обеспечивают управление на всех уровнях модели ВОС, однако более удобны для управления верхними уровнями. CMIS/CMIP позволяют в рамках модели ВОС предлагать
жизнеспособные стандарты для прикладных программ управления сетями связи.
Протоколы CMIS/CMIP разрабатывались при финансовой поддержке правительств
ведущих западных стран и крупных поставщиков сетевого и вычислительного оборудования.
Стандарты CMIS/CMIP превосходят конкурирующий стандарт SNMP по
уровню решений проблем информационной безопасности. В частности, поэтому в
версии 3 протокола SNMP существенное внимание уделено именно вопросам информационной безопасности. Стандарты CMIS/CMIP имеют много функций контроля, управления и поддержки сложных инфраструктур современных сетей связи. Ориентация на объекты управления и объектно-ориентированный подход позволяет
стандартам CMIS/CMIP оставаться базовыми в концепции TMN.
Из имеющихся недостатков CMIS/CMIP основным считается отсутствие полного набора реализаций стека сетевых протоколов ВОС на основе принципов управления, заложенных в CMIS/CMIP. Протоколы модели ВОС в целом подобны стеку
протоколов TCP/IP: и те и другие разработаны, чтобы быть независимыми от производителя сетевого оборудования, и используют принципы архитектуры ВОС. Однако
существуют значительные различия между CMIP и TCP/IP.
Например, в рамках стека протоколов в CMIP выполняются все функции коммуникации, которые выполняет TCP/IP, плюс дополнительные функции. Таким образом, в рамках ВОС имеется полный пакет для организации управления. Однако для
увеличения возможностей и функциональной законченности протокола ВОС требуются значительное увеличение системных ресурсов и усложнение программно обеспечения управления. Поэтому протоколы CMIS/CMIP не нашли широкого применения при массовом коммерческом выпуске сетевых средств для компьютерных коммуникаций. С середины 1990−х годов интересы разработчиков и производителей
привлекли более простые и по−своему эффективные разработки в рамках протокола
сетевого управления SNMP.
Для работы в сетях, не полностью реализующих модель ВОС, был разработан
стек протоколов CMOT (CMIS/CMIP поверх TCP/IP), но в целом данный стек протоколов применяется редко, и, следовательно, данное решение нельзя признать полностью удовлетворительным для реализации модели управления ВОС [11].
Если на большинстве сетей связи в перспективе будут использоваться стеки
протоколов, полностью реализующие модель ВОС, это несомненно обеспечит самое
широкое применение CMIS/CMIP, в первую очередь на крупных телекоммуникационных сетях.

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

124

Источники информации к главе 5.
1. Гольдштейн Б.С. Сигнализация в сетях связи. – М.: Радио и связь,1997.
2. Петровский А. Командный язык программирования Tcl (Tool Command Language). – М.: Майор, 2001.
3. CMIP/CMIS

Object
Oriented
Network
Management.
http://www.cellsoft.de/telecom/cmip.html 16.01.2001
4. CMIP Services and Topology Agent Programming Guide. Document Number: SC316544-00.
http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ISTP7000/CCONTENTS
25.03.2002
5. CMIS/C++: Application Programming Interface/ TMF 041. − 2000. − Issue 1.1.
http://www.tmforum.org/sdata/documents/TMFC1402%20TMFC780%20TMF041.pdf
3.02.01
6. Divakara K. Udupa TMN: Telecommunications Management Network. – McGrawHill. − 1999
7. ITU-T: Recommendation X.711. Information technology − Open Systems
Interconnection − Common management information protocol. − 1997.
8. Kernchen M., Schoenwaelder J. A Tcl interface to the CMIP protocol.
http://chaos.iu.hioslo.no/doc/tclman/scotty218/cmip.n.html 18.04.2002
9. Raman L. CMISE Functions and Services/IEEE Communications Magazine. − 1993. −
Vol. 31, № 5.
http://www.comsoc.org/livepubs/surveys/public/raman/raman.html 4.04.01
10. Ranganathan Parasuram The Common Management Information Protocol (CMIP).
http://www.ittc.ukans.edu/~ram/docs/801/cmip.html 17.01.01
11. RFC 1095. The Common Management Information Services and Protocols for the
Internet (CMOT and CMIP). − October, 1990.

Глава 5. Версия 2.0

А.Ю. Гребешков

Стандарты и технологии управления сетями связи

127

6. ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ И ИНТЕРФЕЙСЫ
УПРАВЛЕНИЯ TMN
6.1 Функции управления и интерфейсы TMN
Под функций управления TMN понимается совместное взаимодействие между
прикладными процессами в управляющей и управляемой системе с целью управления
телекоммуникационными ресурсами.
Множество функций управления TMN описано в Рек. МСЭ−Т M.3200. В последующих рекомендациях серии МСЭ−Т M.32xx для некоторых видов связи и служб связи введены индивидуальные услуги управления. Услуги управления TMN могут быть
разбиты на множества, вплоть до отдельных функций управления. Базовое множество
функций TMN, соответствующее функциональным областям для семиуровневой
модели ВОС, описано в Рек. МСЭ−Т M.3400. Функция управления отражает заключительный этап в определении требований к управлению тем или иным объектом или
функциональной областью [17, 18]. Эти требования предъявляются прежде всего со
стороны пользователей системы управления в связи с необходимостью реализовать те
или иные задачи управления. Разумеется, следует учитывать специфические особенности тех или иных систем связи. В частности, при разработке системы управления
ОКС№7 следует учитывать наличие в ней базовой процедуры коррекции неисправности
и встроенных процедур администрирования, технической эксплуатации, тестирования и
проверки.
В дальнейшем функции управления находят своё воплощение при разработке
информационной модели управления и допускают многократное использование в различных услугах управления.
Общий обзор услуг управления TMN содержится в Рек. МСЭ−Т M.3020. Услуги
управления отдельными сетями и службами связи выполнены в следующих рекомендациях:
- Рек. МСЭ−Т M.3207.1 «Управление широкополосной ЦСИС» (действует с 05.1996
г.).
- Рек. МСЭ−Т M.3208.1 «Услуги TMN для выделенных сетей связи и перестраиваемых физических сетей связи: Услуги для выделенной линии» (действует с 10.1997
г.).
- Рек. МСЭ-Т M.3208.2 «Услуги TMN для выделенных сетей связи и перестраиваемых физических сетей связи: Управление соединениями в рамках услуги подготовки присоединения выделенной линии» (действует с 03.1999 г.).
- Рек. МСЭ-Т M.3208.3 «Услуги TMN для выделенных сетей связи и перестраиваемых физических сетей связи: Виртуальная частная сеть» (действует с 02.2000г.).
- Рек. МСЭ-Т M.3208.3 «Услуги управления TMN для управления безопасностью в
сети IMT-2000» (действует с 01.2001).
- Рек. МСЭ-Т M.3211.1 «Услуги управления TMN: Управление неисправностями и
техническими характеристиками сети доступа ЦСИС» (действует с 05.1996).
В перечисленных рекомендациях описаны некоторые специфические функции
управления TMN. Все функции управления описываются таким образом, чтобы быть
независимыми от конкретных протоколов и программных языков реализации.
Рек. M.3200 предусматривает для описания услуги управления шаблон, согласно
которому каждая услуга управления и должна быть описана в общем виде по схеме,
представленной в табл. 6.1 (на основании Рек. МСЭ-Т М.3200, 1997 г.):
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

128

Администрирование поль+
+
+
+
зователями
Управление обеспечением
+
+
+
+
+
+
сети (Network Provisioning)
Управление работами на
+
+
+
+
+
+
сети (Work Force Management)
Управление тарифами, на+
+
+
+
+
числениями и расчётами за
услуги связи
Администрирование каче+
+
+
+
+
+
ством услуг связи и рабочими
характеристиками
сети
Измерение нагрузки и ана+
+
+
+
+
+
лиз результатов измерения
Управление нагрузкой
+
+
+
+
+
+
Администрирование мар+
+
+
+
+
шрутизацией и системой
нумерации
Техническая эксплуатация
+
+
+
+
+
+
и управление неисправностями
Управление безопасностью
+
+
+
+
+
+
Примечание. + означает, что область управления нуждается в услуге управления.

Сети передачи данных

TMN

Первичные сети
связи

ЦСИО

ОКС№7

Интеллектуальные
сети

Услуга
управления

Системы
подвижной
связи

Функциональные
области
управления

ТФОП

Таблица 6.1

+

+

+

+

+

+
+

+

+

+

+

+
+

+
+

+

+

+

+

Каждая услуга определяется в рамках данного шаблона и далее представляется в
виде компонентов. К примеру, в Рек. МСЭ−Т M.3200 содержится услуга управления
«Техническая эксплуатация и управление неисправностями». Эта услуга, очевидно,
требуется для таких объектов управления, как «ТФОП», «Первичные сети связи»,
ЦСИС и т.д., как показано в таблице 6.1, т.е. для всех управляемых сетей связи. Управление технической эксплуатацией обеспечивается следующими группами функций
управления : «Наблюдение за неисправностями», «Тестирование», «Администрирование в условиях аварийной ситуации».
Группа функций управления «Наблюдение за неисправностями» включает в себя
множество функций, таких как «Сообщение о неисправности», «Обобщение данных о
неисправности» (alarm summary), «Критерий выбора состояния неисправности» (alarm
event criteria), контроль журналирования сообщения о неисправностях, корреляция и
фильтрация аварийных сообщений. Группа функций «Сообщения о неисправности»
включает в себя такие функции TMN, как «Сообщение о неисправности», «Маршрутизация сообщения о неисправности» (route аlarm report), «Запрос истории повреждения»
(request alarm history).
Определения функциям управления даны в Рек. МСЭ−Т M.3400. Например,
функция «Маршрутизация сообщения о неисправности» определена следующим образом: «Программа−менеджер определяет для программы−агента адрес или адреса назначения для заданного множества сообщений о неисправностях».
В итоге создаётся следующая иерархия услуг и функций управления:
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

129

услуга управления − «Управление техническим обслуживанием»;
группа функций управления − «Наблюдение за неисправностями»;
множество функций управления − «Сообщения о неисправности»;
функция управления − «Маршрутизация сообщения о неисправности».
Для интерфейсов TMN можно сформулировать следующие общие требования по
функциональности:
- Управление сессией − система сетевого управления должна получить сообщение в
случае, если обнаружен обрыв информационного обмена.
- Управление знаниями − при управлении через интерфейс TMN каждый из взаимодействующих элементов должен быть равноправным и иметь информацию о состоянии другого элемента.
- Поддержка нескольких одновременно работающих систем управления − объект
управления может управляться различными приложениями на основе различных OS
и должен генерировать соответствующие уведомления для каждого приложения
управления.
- Поддержка отношения вхождения − например, на уровне оборудования, когда местонахождения сетевого интерфейсного модуля идентифицируется на основе данных о номере слота (места на полке), номере полки и номере статива.
- Обеспечение коммуникативности − поддержка операций управления должна осуществляться как в асинхронном, так и в синхронном режиме. Синхронный режим
операций предусматривает, что предварительно проверяется готовность объектов
управления к выполнению той или иной операции. Если хотя бы один объект не
может выполнить операцию, то она не осуществляется.
- Подтверждения о результатах операциях − интерфейс должен выдавать положительные или отрицательные подтверждения о завершении операции.
Подробный перечень требований к интерфейсам можно найти в документе [3]. В
документе [16] рассматриваются общие требования к интерфейсам TMN. Эти требования затрагивают в том числе и требования к проектированию, построению и к проверке
на соответствие стандартам TMN. Основной целью проверки является оценка степени
взаимодействия различных составляющих систем сетевого управления через
применяемые интерфейсы. Взаимодействие элементов системы должно обеспечить
единство системы управления в той мере, в какой это требуется для оператора связи и
для реализации функций управления. Детально проформа проверки интерфейсов на
соответствие требованиям TMN описана в Рек. МСЭ−Т Q.823.1 «Management Conformance Statement Proforma», 1997 (Проформа утверждений соответствия управлению).
1)
2)
3)
4)

6.2 Описание интерфейса Q
Интерфейс Q (ранее интерфейс Q.3) является стандартным интерфейсом управления между элементом сети (адаптером) и OS. Интерфейс Q включает все уровни модели ВОС с использованием отдельных протоколов на каждом уровне для реализации
интерфейса TMN. Подробно реализация транспортного уровня интерфейса Q представлена в Рек. МСЭ−Т Q.811, реализация верхних уровней интерфейса Q в рамках модели
ВОС представлена в Рек. МСЭ−Т Q.812. Дополнительно в Рек. МСЭ−Т G.784 представлено описание интерфейса Q для управления сетью первичной цифровой иерархии
SDH.

Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

130

Общий вид стека протоколов модели ВОС, используемых при реализации интрефейса Q, представлен на рис. 6.1.
Прикладной уровень управления (приложения управления)

Специфические ASE управления

FTAM
ISO 8571

CMIP

ASCE

ASCE

ROSE

X.227 X.217

X.227 X.217

X.219 X.229

Презентационный уровень

Сессионный уровень

X.226 X.209 X.216

X.225 X.215

Транспортный уровень
ISO 8473-3 (CLNS)
ISO 8208 X.25
уровень пакета
ISO 7776 LAPB
X.25 уровень
звена данных
X.21 / X.21 bis
V.35 G.703

ISO 9595 ISO 9596

X.224 X.214

ISO 8473-3 (CLNS)

ISO 8473-4 (CLNS)

ISO 802.3 LCC
ISO 802.3 M AC

Q.921 LapD

ISO 802.2
Ethernet

SDH DCC
2M TS n

CLNP/CONP
AAL5
ATM
Физическая сеть

Сетевой
уровень
Канальный
уровень
Ф изический
уровень

Рис. 6.1 Реализация интерфейса Q
На физическом, канальном и сетевом уровнях обеспечивается маршрутизация
информации управления в DCN, которая передаётся через интерфейс Q. Уровни с
транспортного по прикладной обеспечивают управление соответствующими PDU согласно принципам, описанным в главе 2.
Передача файлов с PDU на прикладной уровень может осуществляться средствами протокола управления доступом при передаче файлов (File Transfer Access Method,
FTAM). CMISE обеспечивает своего рода шлюз к программному обеспечению менеджера или агента. Это программное обеспечение по сути и выполняет функции интерфейса Q, так как поддерживает описание и поведение объекта управления, выполненное
средствами GDMO/ASN.1 или CORBA/IDL (см. главу 7).
На сетевом уровне данные интерфейса Q могут передаваться, например, через
канальный временной интервал в первичном групповом такте E1 по принципу “из
конца - в конец”. Это характерно для управления удалёнными элементами сети. При
расположении объектов управления и рабочей станции управления на одном объекте в
качестве транспортной основы для передачи данных интерфейса Q используется локальная вычислительная сеть.
Прикладной уровень предлагает две услуги : услуги CMISE для управления и
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

131

услуги протокола FTAM для передачи файлов с целью загрузки программного обеспечения. FTAM использует услуги ASCE, в то время как CMISE использует услуги как
ACSE, так и ROSE. Уровень представления в стеке интерфейса Q обеспечивает кодирование данных с помощью ASN.1 и BER. На данном уровне используются следующие
стандарты:
- Рек. МСЭ−Т X.216 − Определение услуг уровня представления;
- Рек. МСЭ−Т X.226 − Спецификация протокола уровня представления, ориентированного на установление соединения между приложениями;
- Рек. МСЭ−Т X.209 − Спецификация BER для ASN. 1.
Сеансовый уровень обеспечивает управление сессией (сеансом), т.е. открытие и
закрытие сессии между взаимодействующими приложениями. В случае потери соединения между приложениями сеансовый уровень пытается это соединение восстановить.
Если соединение прерывается на долгое время, сеансовый уровень может завершить
данное соединение и создать новое. Эти действия прозрачны для уровня представления
и прикладного уровня. Сеансовый уровень в стеке интерфейса Q обеспечивает синхронизацию в потоке передаваемых и принимаемых протокольных блоков данных (пакетов). На сеансовом уровне используются следующие стандарты:
- Рек. МСЭ−Т X.215 − Определение услуг сеансового уровня;
- Рек. МСЭ−Т X.225 − Спецификация протокола сеансового уровня, использующего
установление соединения между приложениями.
Транспортный уровень обеспечивает оконечные соединения и осуществляет контроль потока данных, т.е. информация передаётся только в том случае, когда адресат
позволяет источнику передавать сообщения. Это предупреждает ситуацию, при которой
информация посылается быстрее, чем она может быть обработана получателем. Имеется несколько протоколов транспортного уровня.
Транспортный уровень осуществляет выявление ошибок и их коррекцию в пакетах данных, например, в случае, если данные были повреждены при передаче или переприёме. Если поле данных в протокольном блоке, который пришёл с верхних уровней,
слишком велико, то транспортный уровень при передаче осуществляет их разбиение на
блоки (пакеты) меньшей длины и обратную процедуру сборки на приёме.
На транспортном уровне используются следующие стандарты:
- Рек. МСЭ−Т X.214 − Определение услуг транспортного уровня;
- Рек. МСЭ−Т X.224 − Протокол предоставления транспортных услуг, ориентированных на установление соединения;
- ISO 8602 − Протокол предоставления транспортных услуг, не ориентированных на установление соединения.
Сетевой уровень обеспечивает маршрутизацию пакетов и доставку пакетов
данных к любому узлу сети. Данные процедуры могут быть представлены в виде двух
составляющих:
- основная процедура доставки пакета данных сводится с передаче пакета от одного
узла к другому на основании локальной таблица маршрутизации. Этот процесс передачи определяется с помощью сетевого протокола передачи без установления соединения (Connectionless Network Protocol, CLNP);
- усовершенствование CLNP состоит в автоматическом создании и обновлении локальной таблицы маршрутизации. Этот процесс описывается протоколами обмена
между оконечной открытой системой (End System, ES) и промежуточной открытой
системой (Intermediate System, IS) или протоколом IS−IS.
Формат пакетов данных, в частности кодирование адреса и данные, определен в
CLNP.
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

132

На сетевом уровне используются следующие стандарты:
- ISO 8348 – Спецификации элементов услуг сетевого уровня на границе сетевого и
транспортного уровня. Здесь же определяются услуги протокола c установлением
соединения (Connection-mode Services, CONS) и без установления соединения (Connectionless-mode Services, CLNS);
- ISO 8473-1 – Услуги передачи без установления соединения;
- ISO 8473-2 – CLNS на сетях ISO 8802;
- ISO 8473-3 – CLNS на сетях X.25;
- ISO 8473-4 – CLNS передачи данных в рамках модели ВОС;
- ISO 8473-5 – CLNS в коммутируемых B-каналах ЦСИС.
Канальный уровень обеспечивает определение ошибок и коррекцию данных на
уровне битов. Оконечное соединение организуется с помощью протокола LapD (link
access procedure D-channel, процедура доступа к линии D−канала), описанного в Рек.
МСЭ-Т Q.921. Преобразование данных протокола LapD с помощью услуг канального
уровня описано в Рек. МСЭ-Т G.784. Соединение через Ethernet использует протокол
управления логическим каналом (logical link control, LLC). Семейство протоколов X.25
использует протокол высокого уровня для управления каналом данных (high-level data
link control protocol, LapB), который определён в ISO 7776.
В итоге интерфейс Q охватывает все уровни модели ВОС. Важной задачей является правильная спецификация интерфейса Q на верхних уровнях этой модели.
Спецификации для программно-аппаратной реализации интерфейса Q в основном разрабатываются с помощью объектно−ориентированного подхода различными
международными институтами по стандартизации, такими как Европейский институт
стандартов электросвязи (ETSI), МСЭ-Т, ISO и такими производственными консорциумами, как ATM Форуму (ATM Forum). В частности, ATM форум разрабатывает спецификации для интерфейсов управления оборудованием, использующим асинхронный
режим переноса (Asynchronous Transfer Mode, ATM).
Спецификации интерфейса Q создаются с помощью объектных моделей, которые затем могут быть реализованы с помощью различных языков программирования и
применяться для управления телекоммуникационным оборудованием различных производителей. В спецификации не существует универсальной, всеобъемлющей информационной модели. Это связано с тем, что весьма затруднительно дать корректное абстрактное описание всех свойств и особенностей элемента сети. В итоге для одного и того
же
типа
телекоммуникационного
оборудования
с
помощью
объектно−ориентированного подхода может быть разработано несколько информационных
моделей интерфейса Q, причём каждая модель затрагивает одну из функциональных
областей управления или относится к управлению одной группой оборудования. Это
подтверждается анализом многочисленных рекомендаций ETSI [6–9, 24] и аналогичных
рекомендаций МСЭ-Т, которые описывают модель интерфейса Q для управления конфигурацией и неисправностями сетью доступа и портами пользователя на базе интерфейсов V.5.1, V.5.2. По адресу www.etsi.org можно найти множество спецификаций
интерфейса Q для управления различными сетями и оборудованием связи. Безусловно
актуально, с учётом предполагаемого повсеместного перехода к повременному учёту
местных телефонных соединений, ознакомление с Рек. МСЭ-Т Q.825 «Спецификация
приложений управления на интерфейсе Q.3: Подробная запись о состоявшемся соединении» (введено в действие с 06.1998 г.).
Как уже говорилось, каждая из упомянутых моделей (спецификаций) интерфейса
Q построена по одинаковой схеме, принятой в объектно−ориентированном подходе.
Рассмотрим эту схему в самых общих чертах на примере спецификаций ETSI.
В первую очередь даётся определение всех используемых терминов спецификаГлава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

133

ции. Далее строится диаграмма взаимоотношений сущностей (Entity Relationships diagram, ER−diagram), или диаграмма «сущность − связь». Под сущностями здесь понимаются управляемые объекты или элементы объектов в общем виде. Как правило, рекомендуется применять стандартные зарегистрированные объекты из библиотеки ETSI
или рекомендаций МСЭ-Т. Данный подход подробно рассматривался в главе 4 при обсуждении вопроса об информационных моделях управления. При спецификации интерфейса Q информационная модель применяется на практике для решения прикладной
задачи управления.
После построения ER−диаграммы строится схема с отношениями наследования
и схема имён объектов управления (связывание имён).
Следующим шагом является описание информационной модели интерфейса. В
информационную модель включаются все управляемые объекты, доступ к которым
осуществляется через интерфейс Q, а также атрибуты объектов, состав операций, допустимых над объектами, и описание уведомлений, которые выдаются по результатам
операций.
Завершает описание интерфейса Q список классов объектов управления, которые
импортированы из других рекомендаций ETSI, ISO или МСЭ-Т, а также (при необходимости) модули GDMO с описанием классов объекта управления.
В итоге функциональные возможности интерфейса Q определяются тем,
насколько проведённая работа по спецификации интерфейса соответствует реальным
характеристикам и возможностям оборудования. Функциональность интерфейса Q
можно определить путём анализа его информационной модели, в частности, состава
класса управляемых объектов, описания их возможных состояний, а также допустимых
операций на объектах.
К примеру, пусть создаётся спецификация интерфейса Q для управления абонентским комплектом. В модели отсутствует описание состояний абонентского комплекта с атрибутами «комплект административно заблокирован» и «комплект разблокирован» и допустимыми операциями («изменить состояние комплекта»). Следовательно, оператор будет лишён возможности заблокировать доступ к услугам связи для злостного неплательщика, так как отсутствует соответствующий раздел модели, позволяющий реализовать операцию административной блокировки. Проблема в том, что
программа-менеджер попросту не «увидит» в программе-агенте и в базе MIB требуемых возможностей по блокировке – ведь их не описали в информационной модели.
С заданием по спецификации интерфейса Q может справиться специалист, владеющий инструментарием GDMO и понимающий логику работы телекоммуникационного оборудования. Такие специалисты встречаются достаточно редко. Поэтому на
практике при создании системы сетевого управления специалисты оператора связи
пользуются теми возможностями интерфейса Q, которые предлагаются производителем
телекоммуникационного оборудования или поставщиком системы сетевого управления.
В частности, набор функций интерфейса Q, которые применяются для управления АТС может выглядеть так, как показано в табл. 6.2 [2,23]. Анализ данных табл. 6.2
показывает, что информационная модель интерфейса Q для управления данными абонента включает/ссылается на данные пользователя (тип абонентского устройства, категория абонента, поддержка ЦСИС). Услуги управления абонентскими данными, которые доступны через интерфейс Q, включают, например, определение вида передаваемого сигнала (аналоговый или цифровой), определение вида информации, которая передаются (например, телефония или факс), использование дополнительных услуг (например, переадресация входящего вызова, конференц-связь, телематические услуги).
Таблица 6.2
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

Управляемая
область
Управление
данными абонента

Управление нагрузкой

Управление
системными ресурсами

134

Функции управления
Обеспечение предоставления услуг ТфОП
Обеспечение предоставления услуг ЦСИС
Управление услугами Centrex
Тестирование и мониторинг абонентских и соединительных
линий
Маршрутизация потоков вызовов
Управление телефонной нагрузкой
Управление ОКС№7
Измерение нагрузки
Управление производительностью сети.
Обеспечение живучести при повреждениях
Обработка событий
Журналирование
Управление интерфейсом V.5
Сбор данных об использовании оборудования
Управление безопасностью
Управление программным обеспечением узла

Модель интерфейса Q для управления телефонной нагрузкой описывает функции управления трафиком, связанные с обработкой вызова в телефонной сети общего
пользования ТфОП и ЦСИС. Цель управления нагрузкой состоит в обеспечении возможности успешного завершения соединением для максимально возможного количества поступивших вызовов при различных условиях эксплуатации узлам коммутации
(нормальный режим и перегрузка).
Управление маршрутизацией потоков вызовов связано с функциями анализа телефонного номера, для определения источника и адресата и с функциями маршрутизации, требуемых, чтобы направить обращение к адресату внутри или во вне АТС.
В итоге, для того чтобы реализовать информационную модель интерфейса Q
только в описанном выше объёме, необходимо расширить стандартизированные МСЭ-Т
объектные модели, дополнив их специфическими классами объектов управления. Например, пусть имеется модель интерфейса Q, обеспечивающая управление оборудованием и автоматизацию эксплуатации городской АТС. Очевидно, что успешное применение такой модели возможно только в том случае, когда физические компоненты реального оборудования в полной мере и достоверно отождествлены с объектными классами, полученными из базовых стандартизированных объектных классов МСЭ-Т. Полная аппаратная структура АТС может затем представляться посредством соединения/объединения или других операций над классами объектов управления.
В настоящее время большинство спецификаций интерфейса Q основаны на базовых принципах управления, определенных в рекомендации МСЭ-Т (ITU-T) серии
X.700 и M.3100. Например, все логические объекты, которые описывают внешний доступ к АТС (например, доступ абонента), моделируются как подклассы объектных классов точки доступа согласно Рек. M.3100. Специфические функции эксплуатации оборудования (например, функции диагностики) моделируются с использованием дополнительных программных библиотек.
В итоге при стремлении к универсализации интерфейса Q на практике для каждого вида/типа оборудования связи реализация этого интерфейса будет иметь свои особенности.

6.3 Описание интерфейса X
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

135

В качестве примера операций и возможностей интерфейса X рассмотрим управления установлением, поддержкой и разъединением соединения между операторами
А и Б через первичную цифровую сеть SDH оператора В. Сети SDH разделяются
на транспортные слои [5]. Слой каналов обеспечивает передачу пользовательской
информации из конца в конец; слой трактов поддерживает транспорт виртуальных
контейнеров (Virtual Container, VC) и делится на тракты низшего и высшего порядков. Слой секций гарантирует передачу циклов SDH (STM-n) между сетевыми
узлами. Сеть может быть разбита на подсети, которые связываются между собой
звеньевыми соединениями. Иерархическая модель сети SDH в соответствии с европейской схемой [5], данные ЛОНИИС, ETSI EN 300 147 V1.4.1. «Transmission
and Multiplexing (TM); Synchronous Digital Hierarchy (SDH); Multiplexing structure»,
2001. [Передача и мультиплексирование; Синхронная цифровая иерархия; Структура мультиплексирования].
Слой каналов
VC-12

VC-2

VC-3

Слой трактов
низшего порядка
Слой трактов
высш его порядка

VC-4

Слой мультиплексных секций
Слой секций
Слой регенерационных секций

Слой физической среды

Рис. 6.2 Иерархическая модель SDH
На уровне сети управляемыми объектами являются элементы сети (мультиплексоры или кросс-коннекторы), линии между ними и тракты VC. Тракты VC соединяются
через промежуточные звенья с помощью оконечных элементов первичной сети. В результате создаётся трасса или путь. Сетевые тракты могут создаваться ручным или автоматическим выбором трактов VC-n на каждом звене пути между требуемыми элементами сети. Основные функции уровня управления сетью SDH связаны с обслуживанием
трактов VC-12,VC-2,VC-3,VC-4 по принципу «из конца в конец». Тракты VC-n образуются на свободных позициях синхронного транспортного модуля STM-n между двумя
оконечными узлами передачи.
Функциональные возможности интерфейса X рассмотрим на примере двух составляющих процесса управления, а именно управление организацией трассы, или пути
(path provisioning) и управление неисправностями (fault management).
Для описания интерфейса X управления между OS оператора А, Б и В (рис. 6.3)
ETSI рекомендует использовать методологию, которая называется групповым, или ансамблевым подходом (ensemble approach). Для того, что бы описать услуги управления
организацией пути или услуги управления неисправностями SDH, предполагается, что
в каждой OS есть как программы−менеджеры, так и программы−агенты.
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

136

OS
оператора
В

Интерфейс X между
операторами А и В

Инт ерфейс X
между
операт орами Б и В

x

x
OS
оператора
А

x
Инт ерфейс X
между операт орами
АиБ

OS
оператора
Б

Рис. 6.3 Интерфейс X при межоператорском взаимодействии
Конечной целью группового подхода является полное описание того, как услуга
управления предоставляется на данном интерфейса. В результате специфицируется
группа услуг управления (Ensemble Service, ENS), как это показано на рис. 6.4. Сама
группа услуг, или ансамбль является множеством функций управления (Management
Function Sets, MFS), которые достаточно полно характеризуют специфические возможности данного интерфейса и используют одну или несколько базовых функций управления (basic Management Functions, MF), каждая из которых описывает некоторое отдельное сообщение, которым OS обмениваются через интерфейс.
ENS

MFS

MF

MFS

MF

MFS

MF

MF

Рис. 6.4 Ансамблевый подход к описанию услуг управления
Ансамблевый подход планировалось использовать при разработке межоператорской системы управления для пан−Европейской магистрали SDH. Рассмотрим её
более подробно [12]. На практике пан-Европейские магистрали SDH имеют такие компании как British Telecom (длина ВОЛС до 45 тыс. км, 36 тыс. км – сети партнёров, на
2000 г. по плану были соединены 14 городов, потом по 200 городов ежегодно), Cable&Wireless (7,2 тыс. км, 26 городов с увеличением до 40 городов), KPNQWest (14,7
тыс.км., 39 городов по плану), Telia (10 тыс. км, 9 городов) (данные из бюллетеня «В
мире телекоммуникаций», выпуск 6, июнь 2000 г., ЗАО «ЭКСПО-ТЕЛЕКОМ»).
Техническая сторона задачи выглядит следующим образом. Имеется сеть SDH
исходящего оператора А, сеть SDH оператора назначения Б и транзитная сеть оператора
В (рис. 6.5). Практически это вариант встречается повсеместно, когда цифровые первичные сети крупных областных и краевых центров России взаимодействуют через магистральную первичную сеть ОАО «Ростелеком».
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

Оператор В

S64

Оператор А

VC-12 в
VC-4

STM -16

S64

S16

STM-64

Путь

S16

S64

STM -16

S16

S16

S16

S64

S64

137

Оператор Б
VC-12
в VC-4

Рис. 6.5 Организация связи между операторами первичной сети связи
Основной целью межоператорского управления первичной цифровой сетью SDH
в рассматриваемом примере является автоматизация управления трактом VC−12, который мультиплексирован в тракт VC−4. Управляемые ресурсы состоят из соединений
звеньев (Link Connections, LC), VC−4 и подсетей оператора А, Б и В. При этом точкой
пересечения LC и условной границы сети операторов управляет только одним из оконечных операторов; каждый из операторов А, Б или В может уведомить других операторов о тех сетевых ресурсах, которые он желает сделать доступными для использования третьей стороной. Подсети, где тракт VC−12 начинается и заканчивается, называются шлюзами [12].
В данном случае не существует центральной базы данных с информацией
управления. Каждый оператор имеет собственные сведения о своей сети и сетях, с которыми он взаимодействует. Таким образом, каждый из операторов ответственен за
распространение данных об изменении своей сети для других операторов связи. В этой
связи существенным является вопрос о количестве сообщений о неисправностях, которые передаются через интерфейс X. Для ограничения числа аварийных сообщений
можно построить систему управления таким образом, чтобы через интерфейс X передавались только аварийные сообщения трактов VC−4 и VC−12. Целесообразно, чтобы
аварийное сообщения получал именно тот оператор, который использует неисправный
ресурс.
Далее рассмотрим группы услуг управления, предоставления пути/трассы (path
provisioning) и управления неисправностями.
Когда оператору А необходимо задействовать для передачи информации тракт
VC−12 на трассе через транзитную сеть оператора В, этот тракт VC−12 и предоставляемое соединение тракта (Deliverablerable Link Connection, DLC) должны быть зарезервированы на выбранной трассе.
Под соединением тракта (link connection) [12] в данном случае понимается некая
транспортная функция (сущность), которая формируется функцией адаптации ближайшего окончания трассы, трейлом сети SDH и функции адаптации дальнего окончания
трассы. В каком-то смысле соединение такта аналогично звену ОКС №7 на уровне 1 и 2
(см. А.В. Росляков, «Общеканальная система сигнализации ОКС №7», М.: Эко-Трендз,
1999, С. 20 - 22). Термин «тракт» в отношении понятия link использовался согласно
принятым определениям в РД «Основные положения развития ВСС РФ на перспективу
до 2005 г.», книга 2, с. 214. Соединение тракта VC-12 осуществляется в слое трактов
низшего порядка.
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

138

Запрос на резервирование посылается исходящим оператором А ко всем операторам вдоль предполагаемого пути. Получаемые оператором А ответы на запросы содержат ID (идентификаторы) оконечных точек трассы по каждому оператору и ID
зарезервированных DLC. Когда все запросы на резервирование удовлетворены, оператор А может активировать (задействовать) трассу, посылая следующие сигналы операторам Б и В:
- запрос на активизацию DLC;
- запрос на установление соединений трактов в подсетях между DLC, которые начинаются и заканчиваются уже известными оконечными точками.
Необходимо предусмотреть возможность частичного освобождения пути, который ещё не был задействован. Процедура отмены резервирования запускается автоматически в том случае, если DLC не был активизирован в течении оговоренного периода
времени.
Множество MFS, которые входят в состав группы предоставления пути, состоят
из следующих функций:
- резервирование множества DLC внутри пути;
- отмена резервирования множества DLC внутри пути;
- отмена резервирования DLC в связи с несостоявшейся активизацией за указанное
время;
- активизация множества DLC или соединения подсети SNC (SubNetwork Connections) внутри пути, которая, как правило, осуществляется сразу после резервирования;
- разъединение пути − деактивизация и отмена резервирования множества DLC или
SNC (Sub Network Connection, соединение через подсеть между окончаниями пути)
внутри пути;
- обновление доступных соединений − обусловленное внутренними причинами изменения доступных соединений (DLC) внутри пути;
- возможность обновления соединения − уведомление, которое обозначает техническую возможность подсети поддерживать установление новых SNC.
Множество функции управления, как показано на рис. 6.4, подразделяются на
функции управления (табл. 6.3), которые, в свою очередь, состоят из запроса и уведомления (сообщения в ответ на запрос).

Таблица 6.3
Множество функций управления
Резервирование DLC

Отмена резервирования DLC
Отмена резервирования по истечении времени
Активизация пути
Глава 6. Версия 2.

Функции управления
Резервирование DLC (DLC reservation)
Распространение по сети изменений в данных о доступных соединениях (Available Connections Change
Dissemination, ACCD)
Отмена резервирования DLC
ACCD
ACCD
Активизация DLC
Установка SNC
А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

139

Множество функций управления
Разъединение пути
Обновление доступных соединений
Возможность обновления соединения

Функции управления
Разъединение DLC
Разъединение SNC
ACCD
Чтение данных о доступных соединениях
Способность распространять по сети информацию об
изменении соединений (Ability to Connect Change
Dissemination, ATCCD)
Способность к чтению данных о доступных соединениях

Группа управления неисправностями обеспечивает передачу сообщений о неисправностях на LC и SNC только операторам, которые используют данные LC и SNC.
Операторы должны поддерживать журналирование всех аварийных сообщений, которые посылаются корреспондирующим операторам. Файл журналирования частично
доступен и другим операторам для того, чтобы сохранить возможность отслеживания
(трассировки) всех случайно потерянных сообщений о неисправностях. Наличие файла
журналирования позволяет оператору А в любое время получить доступ к файлам журналирования другого оператора для ознакомления и проверки. Доступ осуществляется
только в части аварийных сигналов, посланных оператору А (к примеру, сообщений,
которые могли быть посланы или были потеряны).
Когда появляется сообщение о неисправности LC или изменение доступных соединений LC, от группы управления неисправностями может быть послано специальное
межгрупповое сообщение к менеджеру управления предоставлением пути. Далее такое
сообщение будет передано всем операторам для обновления данных о существующей
сетевой ситуации и топологии сети.
Множество MFS, которые входят в состав группы управления неисправностями,
состоит из следующих функций:
- обработка сообщения о неисправности (alarm processing) − получение и распространение сообщения о неисправности по другим получателям и обновление сведений о
состоянии сети;
- журналирование аварийных событий (alarm event logging), которое включает контроль файлов журналирования.
Множество функций управления неисправностями, доступные через интерфейс
X , состоит из отдельных функций управления, как это показано, к примеру, в табл. 6.4.
Каждая функция управления из табл. 6.4 состоит из запроса и уведомления (сообщения
в ответ на запрос).

Таблица 6.4
Множество функций управления

Функции управления

Обработка аварийного сообщения

Распространение по сети аварийных сообщений

Журналирование аварийных событий

Проверка файла журналирования

В заключение рассмотрим обмен запросами и уведомлениями (ответами на запрос), которыми обмениваются программа−менеджер и программа−агент при резервировании DLC (управление обеспечением пути).
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

140

Интерфейс X
Менеджер

Агент
Ответ на запрос

x

Уведомление

Managed Object Class
Managed Object Instance
Reserve connection replay /ответ на запрос
резервирования/
Причины отсутствия
резервирования :
нет свободных DLC в LC;
LC недоступен.

Интерфейс X
x

Менеджер
Запрос

MLink Connections
Connection Id (LCId)
passed /резевирование осущ ествлено/
Connection Id = DLCId
a Network CTP Id = CPId
z Network CTP Id = CPId
failed /резервирование не осущ ествлено/
logical Problem
problem cause = ....
/почему нет резервирования/

Агент
Индикация
появления запроса

M-ACTION c атрибутами :
Mode /Режим работы/
Base Object C lass
Base Object Instance
Action T ype /тип действия/

Confirm ed /c подтверждением/
MLink Connections
Connection Id (LCId)
reserve connection /резервирование соединения/

Программа−менеджер посылает запрос на оперативное резервирование DLC с
помощью сообщения M-ACTION по направлению к классу объектов управления mLink
Connection (рис. 6.6).
Этот класс содержит номер требуемого пути. Резервирование, активизация и освобождение этого DLC осуществляется действиями на этом классе. Объекты данного
класса характеризуются атрибутами для подсчёта доступных DLC. Уведомление
(сообщение) выдаётся, если изменяется значение атрибутов; аварийное сообщение выдаётся в случае разрыва соединения. Если оператор А выдал данное сообщение операторам Б и В, то управляющие системы Б и В идентифицируют поступивший запрос как
действие.
Рис. 6.6. Запрос на резервирование DLC через интерфейс X
При выполнении данной операции необходимо учесть следующее предвари
тельное условие: состояние объекта mLink Connection должно быть установлено в «доступен», а число доступных соединений должно быть больше нуля.
В случае если ситуация позволяет провести резервирование, ответ на запрос содержит идентификаторы зарезервированных DLC (объект управления mDeliverable Link
Connection) и сетевые окончания, соответствующие выбранному DLC (объект управления mNetwork CTP, Connection Termination Point – соединение точки окончания)
(рис.6.7)
Рис. 6.7 Ответ на запрос резервирования DLC через интерфейс X
В случае если запрос на резервирование удовлетворяется, изменяется состояние
управляемого объекта mDeliverable Link Connection, которое становится «зарезервирован» (reserved). Значение атрибута «доступные соединения» (аvailable connections) в выГлава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

141

званном объекте mLink Connection соответственно уменьшается. Кроме того, с помощью функции ACCD выдаётся уведомление об изменении значения атрибута.
Итак, на пример показано, какого рода информацией обмениваются различные
операционные системы через интерфейс X для первичной транспортной сети SDH.
Описание других возможностей управления через интерфейс X доступно в [11].

6.4 Описание интерфейсов F и G
Интерфейс F соединяет рабочие станции WS с OS или с устройствами медиации
(MD) и предназначен для обеспечения доступа пользователя к системе управления
электросвязью. Этот интерфейс может использовать протоколы, которые отличаются от
протоколов для интерфейсов Q и X, и выполныет обмен данными, которые могут использоваться как для внутренней обработки в системе сетевого управления, так и для
обмена информации между системами. Здесь могут применяться языки описания данных GDMO/ASN.1 или IDL (см. главы 4 и 7). В дальнейшем происходит обмен информацией управления между опорными точками f и g. Фактически опорная точка f осуществляет адаптацию информации OS для рабочей станции (точнее, для информационной модели функции рабочей станции), а также может выполнять функцию перевода
информации OS для дальнейшего представления на дисплее оператора; разумеется, выполняется и обратный перевод информации − от оператора для OS.
Информационная модель интерфейса F может включать данные, которые
недоступны, например, элементу сети, но необходимы для обмена между
пользователями системы сетевого управления и OS (MD). К такой информации относятся, например, списки выполняемых заданий (работ) системы управления, расписание
запуска этих работ, информация для поддержки графического интерфейса и т.п. Соответственно в интерфейсе F определены, к примеру, функции управления, приведенные
в табл. 6.5.
Таблица 6.5
Управляемая область
Управление
рабочими характеристиками

Управление повреждениями

Управление конфигураций

Управление
расчётами за услуги связи

Глава 6. Версия 2.

Функции управления
Предоставление информации об измерении трафика
Создание нового графика для сообщений об измерениях трафика
Запрос сообщения об измерении трафика
Список всех запрошенных сообщений
Отмена сообщений об измерении трафика
Аварийное сообщение
Регистрация аварий
Выбор файла регистрации аварий
Аварийное подтверждение
Испытание (множество функций)
Планировка испытаний (множество функций)
Получение подробной информации относительно уровня обслуживания
Проверка состояния, модернизация, отмена уровня обслуживания
Конфигурация управляемого ресурса
Получение информации по выставлению счёта
Согласование счёта
Информация пользователя об оплате счёта
А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

Управление безопасностью

142

Обеспечение безопасности доступа

Непосредственная работа/доступ пользователя к функциям, указанным в табл. 6.5,
осуществляется через интерфейс G рабочей станции [13].
Объектно−ориентированный подход предлагает определённые принципы построения интерфейса G для пользователя системы сетевого управления. Следуя этим
принципам, разработчик проектирует и реализует интерфейс таким образом, чтобы
пользователь получил возможность манипулировать объектами управления и управляемыми ресурсами, которые представлены на экране в виде определённых графических символов. Интерфейс G предназначен для преобразования внутренней информации управления TMN в форму, которая доступна и понятна пользователю. Пользователь
может через интерфейс G реализовывать операции удаления, копирования, передвижения, изменяя тем самым атрибуты объектов управления.
Интерфейс пользователя в TMN можно рассматривать как одну из возможностей
интерактивного взаимодействия между системой управления и внешним агентом. Таким агентом может являться пользователь системы, физическое устройство, прикладная
программа. Интерфейс пользователя позволяет обращаться к той части прикладного
программного обеспечения OS, которая отвечает за представление данных системы. В
то же время вычислительный блок функционирует относительно независимо. Тем
самым повышается устойчивость системы при попытке неправильного или
несанкционированного использования.
Существует несколько стандартов и значительное число рекомендаций,
посвященных разработке интерфейса G. Например, американский национальный стандарт «Спецификация интерфейса G для использования в сети управления электросвязи»
является часть рекомендаций по интерфейсам TMN, которые подготовлены ANSI. Этот
стандарт определяет интерфейс пользователя для реализации функций технического
обслуживания, эксплуатации, администрирования и обеспечения. В этом же стандарте
содержатся руководство по методам разработки интерфейса, которые ориентированы на
пользователя. Достоинство данного стандарта заключается в том, что он не зависит от
способов реализации интерфейса и в основном затрагивает вопросы графического представления информации (символы, графики, таблицы, цветовое решение, командные
слова, а также диалоговый режим, меню программы, заполнение экранных форм, способы манипулирования данными).
Стандарт ISO 9241 «Эргономические требования к работе в учреждении с пультом визуального отображения информации» включает в себя много разделов, посвящённых различным аспектам работы с дисплеями. Только некоторые части этого объёмного документа является международными стандартами. Достоинством этого документа можно считать ориентацию на «человеческий фактор», а не на описание возможностей программного обеспечения. Недостаток данного документа в том, что его разработка потребовала слишком много времени. Разработка интерфейсов осуществлялась
компаниями и фирмами для собственных целей. Для разработчиков интерфейса TMN
представляют интерес следующие части данного стандарта: часть 10 «Принципы диалогового режима», часть 11 «Руководство по использованию», часть 13 «Руководство
пользователя», часть 16 «Прямое манипулирование объектами в режиме диалога».
Организация МСЭ−Т разработала стандарты на интерфейсы пользователя в
рамках Рек. МСЭ−Т серии Z.300 и Z.350.
Из коммерческих стандартов в наибольшей степени задачам TMN отвечает стиль
интерфейса OSF/Motif, а также руководство по разработке приложений для продукта
Hewlett-Packard Open View. Аналогичные руководства имеют компании IBM − «Общий
интерфейс пользователя» (Common User Access, CUA) и компания Microsoft.
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

143

В частности, стиль интефейса, который использует комания Hewlett-Packard в
своём продукте Open View, предусматривает наличие иерархической структуры меню,
которое характеридуется несколькими уровнями иерархии и незначительным
количеством разделов меню на каждом уровне.
Основное меню интерфейса пользователя системы сетевого управления
соответстветствует предназначению системы управления. Пусть система состоит из
нескольких OS (OS для управления сетью SDH, OS для управления сетью PDH, OS для
управления сетью ATM). Главное меню инерфейса каждой OS должно соответствовать
общему назначению OS, а второй уровень экранного меню – отражать специфические
функции каждой OS.
ANSI рекомендует, чтобы экранное меню включало максимум четыре уровня «в
глубину» и не более 10 пунктов для выбора на каждом уровне. Пункты в меню должны
выводиться в последовательности, соответствующей порядку решения задач,
возникающих при сетевом управлении. Можно установить приоритеты пунктов или
разделов меню, например, в соответствии с важностью задачи, с последовательностью
разделов, в алфавитном порядке или согласно частоте использования того или иного
пункта меню.
Заполнение полей данных в экранных формах в процессе диалога − ещё один
важный аспект работы интерфейса пользователя. Экранные формы применяются для
сообщения о неисправностях, для ввода параметров при техническом обслуживании и
эксплуатации, для ввода имени и пароля пользователя в момент начала работы с системой управления.
Прямое манипулирование объектами управления предусматривает графическое
выделение условных символов на экране, передвижение символов, соответствующих
объектам управления, по экрану. Символы на экране, как правило, отображают реальные физические ресурсы управления. Выделение цветом может означать, к примеру,
изменение административного статуса атрибутов объекта с «доступен» на «недоступен», что влечёт за собой невозможность вмешиваться в работу физического объекта.
Условные символы должны быть независимы от языка интерфейса и не предусматривать перевода. Желательно использовать международно признанные символы.
Надписи на объектах на экране, фон текста, сам текст, включая шрифт, должны быть
легко читаемы, а объекты − легко опознаваемы. Если одновременно на экране появляется более пяти различных графических символов и хотя бы один из них не подписан,
то целесообразно вывести на экране легенду с условными обозначениями и указаниями,
что символы означают.
Особую роль при отображении информации управления на экране рабочей станции играют цвета. Как правило, целесообразно одновременно использовать четыре различных цвета, которые не перекрывают друг друга. Цветовое кодирование используется для представления информации о состоянии объекта управления. Кроме того, данные
о состоянии объекта должны дублироваться текстовым сообщением. Цветовой код может использоваться при заливке контуров объекта, различных меток, подписей или
внутренних линий. В табл. 6.6 показаны возможные цвета, используемые для кодирования состояния объектов управления.
Таблица 6.6
Назначение
Общее обозначение

Цвет
Серый

Обозначение
неисправности

Красный
Жёлтый

Глава 6. Версия 2.

Применение цветовой кодировки
Базовые символы, нет идикации состояния объекта
(например, технически исправные объеты)
Критическая неисправность или нештатное состояние
услуги управления
Неисправность, состояние услуг управления штатное
А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

Зелёный
Синий

144

Неисправность устранена или прекратила своё действие
Предупреждение или неопределённое состояние (т.е.
неисправность не обнаружена, но рабочий режим
нештатный)

На рис. 6.8 представлены рисунки с изображением интерфейсов пользователя
при выводе данных о неисправностях (стиль интерфейса OSF/Motif).

Рис. 6.8. Список и анализ неисправностей (по данным ЗАО «Телесофт-Россия»)
Графическое представление сети важно как для управления неисправносятми,
так и для контроля и управления сетевыми маршрутами установления соединений. При
этом одна и та же графическая схема сети на экране может быть использована для
реализации многих услуг управления. Возможен вариант, при котором для каждой
услуги управления на экран выводится соответствующая схема. Схема сети должна
генерироваться автоматически на основании сведений о состоянии и размещении
объектов управления в MIB. Важно, чтобы схема и её элементы периодически обновлялись в соответствии с сетевой ситуацией и в связи с изменением состояния объектов
управления.
Наглядность графики и особенно привязка сетевых объектов к географической
карте облегчает пользователю системы сетевого управления восприятие сетевой ситуации и повышает качество принимаемых решений по управлению сетью. На рис. 6.9 даны примеры графических интерфейсов пользователя системы сетевого управления со
схемой сети.
На экран рекомендуется выводить не более трёх уровней отображения сети:
фоновый рисунок (географическая карта), средний уровень, который включает объекты,
с которыми работает оператор, и передний план, на который выводятся основные
сигналы или данные по управлению. Эти уровни должны различаться по цвету, яркости,
насыщенности и по используемым цветовым решениям.
Помимо графических изображений в интерфейсе G для взаимодействия с
пользователем используются сообщения, которые могут выдаваться в следующих
формах:
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

145

-

короткий и ясный текст;
речевое сообщение (автоинформатор);
звуковые сигналы.
Пользователь должен однозначно воспринимать и интерпретировать сообщение.
Особый раздел сообщений представляют собой инструкции по пользованию
программой в виде Help (раздел меню «Помощь») или контестной подсказки. Эти
сообщения должны, к примеру, указывать пользователю на то, ввод каких данных
ожидает система.
Рис. 6.9 Графическое отображение первичной сети связи
(по данным ЗАО «Телесофт-Россия»)
Сообщения системы (системная информация) генерируется системой управления
для того, чтобы пользователь имел представление о текущих заданиях и действиях
системы. Среди сообщений системы можно выделить следующие (рис. 6.10):
- уведомления;
- сообщения о состоянии системы ;
- информация о выполняемых заданиях;
- предупреждения, т.е. извещение пользователя о потенциальных или появившися
неисправностях и сбоях;
- требование вмешательство пользователя − сообщение о ситуации, в которой для
продолжения действий системы управления требуется вмешательство пользователя;

Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

-

146

запросы системы − предложение пользователю провести выбор одного из разделов
(пунктов) меню.
Рис. 6.10 Управление нагрузкой (по данным ЗАО «Телесофт-Россия»)

Сообщения могут выдаваться на экран в форме “бегущей” строки, в специальном
окне, а аварийные сообщения выдаются в специальной экранной форме поверх всех
элементов интерфейса и сопровождаются звуковым сигналом.
Итак, интерфейс G представляет собой важный элемент в системе сетевого

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

6.5 Методология описания интерфейсов TMN
6.5.1

Общие сведения о методологии описания интерфейсов

Методология описания интерфейсов TMN (Unified TMN Requirements, Analysis
and Design, UTRAD) описывает процесс разработки описаний (спецификаций) интерфейсов TMN. При разработке описаний интерфейсов, а также других объектов TMN необходимо учитывать следующие факторы :
- требования к интерфейсу со стороны пользователя,
- анализ проблемы и постановка задачи,
- технология разработки.
Все перечисленные факторы обозначают RAD (user Requirements, Analysis and
Design) [14,16].
В настоящее время правила для реализации RAD рекомендуют использовать
способ записи данных на языке унифицированного моделирования (Unified Modelling
Language, UML). В то же время допускается пользоваться и другими методологиями
для спецификаций интерфейсов TMN. В настоящее время руководство для применения
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

147

UML к описанию объектов TMN проработано в общих чертах. Детальная проработка
применения UML в настоящее время ведется исследовательскими группами МСЭ-Т.
Принимая во внимание требования о необходимости взаимодействия разнородных
программных средств рамках архитектуры CORBA, а также в целях поддержания
единства технологий разработки средств TMN, UML рассматривается как наиболее
предпочтительная технология (см. приложение 2).
В целом спецификация интерфейсов TMN с точки зрения услуг (сервисов)
управления определена в Рек. МСЭ-Т M.3200. Услуги управления объединяют несколько функций управления, которые детально описаны в Рек. МСЭ-Т M.3400. Приведённые стандартные функции управления могут удовлетворить условиям большинства
случаев управления сетью связи и стать основой для создания новых функций управления.
Методология UTRAD включает три стадии итеративного процесса разработки
спецификаций интерфейсов, причём существуют средства для отслеживания отдельных
этапов разработки интерфейсов (трассирование):
1. Формирование требований пользователя (как правило, это общие требования).
2. Анализ требований и учёт возможностей функций управления.
3. Разработка описания интерфейса или объекта.
Все три стадии разработки описания интерфейсов TMN в рамках UTRAD используют современные информационные технологии, в частности объектноориентированный подход к анализу и разработке описания интерфейсов.
На стадии формирования требований пользователя и анализа проблемы используются средства UML (см. приложение 2) [21, 22]. На фазе разработки может использоваться особая форма записи в рамках парадигмы управления сетями (network
management paradigm), например GDMO.
При завершении каждой из трёх перечисленных стадий формируются следующие документы (данные):
- стадия формирования требований к интерфейсу – требования к интерфейсу;
- стадия анализа – отдельные описания или спецификации для внедрения интерфейса;
- стадия разработки – технологическое описание интерфейса, зависящее от программных средств разработки.
Далее перечисленные стадии рассматриваются более подробно.
6.5.2

Формирование требований к описанию интерфейсов

Требования к описанию интерфейсов условно можно разделить на два класса.
Первый класс требований определяется как бизнес-требования – оценка адекватности
требований для решения проблем управления. Например, предметом бизнес-требований
может стать уровень доступа пользователя к управлению объектом.
Второй класс требований обуславливает детальное описание интерфейсов с тем,
чтобы можно было перейти к осуществлению фазы анализа и разработки интерфейсов.
Для описания двух классов требований могут быть использованы различные методологии. В любом случае, безотносительно к используемой технологии описания, необходимо обеспечить удобочитаемость требований для постановщиков задач и специалистов оператора связи. Сами требования не должны выражаться с помощью языков
программирования, которые понятны только программистам. Это обусловлено необходимостью чёткого и однозначного понимания требований к интерфейсам со стороны
прежде всего специалистов в данной предметной области. Полезно последовательное
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

148

перечисление требований, что позволяет проводить трассировку и отслеживать реализацию требований в период разработки.
Стадия формирования требований включает в себя такие аспекты описания интерфейсов, как определение мер информационной безопасности, области применения
требований, ресурсов управления и функций управления.
Например, описание интерфейса между операционной системой платформы
управления и объекта управления для организации арендованной линии (физической
цепи, пары) связи (Leased Circuit Services, LCS) должно содержать описание возможностей и условий предоставления пользователю услуги «Арендованная линия» а также
описание способов управления услугой «Арендованная линия» со стороны пользователя. Фактически в примере с арендой линии рассматриваются требования к интерфейсу
X между платформой управления и объектом управления с учётом передачи информации через границы сетей. Кроме того, необходимо принять во внимание возможности
интерфейса Q. В целом поддержка услуг по управлению осуществляется провайдером
услуги или оператором связи.
Определение услуг по управлению должно быть независимо от сетевых технологий. Это позволяет использовать несколько информационных технологий для поддержки услуг по управлению. В частности, информация уровня управления сетью не должна
быть представлена на уровне управления услугами. Тем не менее, некоторые услуги по
управлению можно описать таким образом, чтобы сетевые данные или информация
элемента сети были предоставлены пользователю услуг связи. В этом случае передаётся
только существенная часть информации, относящаяся к характеристикам услуги.
Дополнительно в качестве примеров требований можно привести следующие.
Администратор системы может выдвинуть требование, чтобы все компоненты оборудования связи автоматически оповещали о своём техническом состоянии станцию управления каждые 5 секунд. Финансовый управляющий компании может потребовать, чтобы система управления не предоставляла пользователю доступ к услуге до проверки
кредитоспособности пользователя. Отдел по работе с клиентами может указать, что
пользователь должен характеризоваться четырьмя основными параметрами: фамилия,
имя, отчество; почтовый адрес; номер телефона; номер лицевого счёта.
6.5.3

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

На стадии анализа сформированные ранее требования используются для описания взаимодействующих сущностей, их свойств и взаимоотношений между ними. Как
отмечалось в разделе 2.1, под сущностью понимается некоторый активный элемент, обладающий некоторым набором функциональных возможностей. Например, в качестве
сущности могут рассматриваться процедуры управления арендованной линией или каналом связи со стороны пользователя.
В UML сущности называются классами. Описание класса вместе с описанием
интерфейса должно быть доступным для контроля выполнения требований пользователя. В Рек. МСЭ-Т М.3020 определены общие руководящие принципы для использования UML при описании интерфейсов; в то же время для расширения описательных возможностей UML можно использовать традиционный язык спецификаций и описаний
SDL.
Анализ должен быть независим от технологий разработки программной реализации интерфейсов. Например, результаты анализа могут быть документированы с использованием объектно-ориентированного подхода, а для разработки интерфейсов может использоваться не объектно-ориентированная технология.
Информация, сформированная на стадии анализа, включает описание классов,
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

149

описание данных, взаимосвязи между классами, диаграммы взаимодействия объектов,
диаграммы активности и диаграммы перехода состояний. Указанные диаграммы подробнее рассматриваются ниже.
Описание классов включает в себя текстовое описание операций, сигналов (таких, как операция, событие), атрибутов и поведения объекта.
Для проведения анализа необходимы функциональное разбиение, определение
информационных потоков, составление диаграмм классов, включая взаимосвязи между
классами, а также разработка таблиц состояний объектов.
На стадии анализа необходимо обеспечить детальное описание функций управления и определить взаимодействие между этими функциями. Информационные потоки, определяемые каждой функцией управления, должны содержать таблицы с описанием потоков и данными о том, является ли информационный поток обязательным, необязательным или его появление обусловлено рядом условий. При этом необходимо
чётко определить такие условия.
На стадии анализа может формироваться модель состояний системы. Переходы
системы из одного состояния в другое могут описываться с помощью таблиц или диаграмм, определяющих события, вызвавшие переход из одного состояния в другое. Ещё
один важный аспект анализа – это описание случаев ошибок или исключений из обычных правил.
Как правило, для моделирования процессов взаимодействия объектов на стадии
анализа можно использовать диаграммы последовательностей, которые целесообразно
применять для описания управляющих взаимодействий с в рамках информационной
модели агент-менеджер.
На стадии анализа основными определениями, которыми пользуется разработчик, являются операции и стереотипы. Эти элементы описания могут использоваться
для определения множества атрибутов и передачи уведомлений. При этом стереотипы
могут включаться в определение классов и в диаграммы взаимодействия. Подробнее
стереотипы рассматриваются в приложении 2.
На стадии разработки создаётся детальное описание интерфейса или объекта
TMN. При этом используется целевой язык описания. В контексте использования в
TMN семиуровневой модели ВОС разработка описаний интерфейса представляет собой
описание информационной модели управления с использованием шаблонов GDMO для
классов объектов управления, атрибутов, поведения объектов, уведомлений, действий,
ошибок и исключений из правил. Синтаксис записи использует нотацию ASN.1.
Как отмечалось в разделе 4.3, в GDMO классы управляемых объектов характеризуются свойствами, доступными для управления. Для описания элементов интерфейса
необходимо использовать дерево наследований (старшие классы и подчинённые классы) с тем, чтобы извлечь максимальную пользу из многократного использования сделанных ранее описаний. По Рек. МСЭ-Т X.722 классы объектов описываются с применением шаблонов. Шаблоны описания, составляющие важную часть информационной
модели, должны бы быть маркированы или помечены согласно правил Рек. МСЭ-Т
X.722 с помощью значений объектных идентификаторов ASN.1. (см. раздел 4.3). Для
классов объектов, которые уже описаны в других рекомендациях МСЭ-Т или в документах ISO, достаточно сделать ссылки на соответствующие описания.
При использовании в TMN технологии CORBA информационная модель разрабатывается с помощью языка IDL. На стадии разработки рекомендуется, чтобы описания UML, выполненные на стадии требований и анализа, были дополнены описаниями
поведения или режима работы объекта управления. К примеру, описание поведения
управляемого объекта может содержать ссылку на диаграмму состояний (последовательностей событий) и на классы, определённые на стадии анализа.
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

150

6.6 Применение UML для описания интерфейсов TMN
6.6.1

Диаграмма состояний

Одной из часто используемых в TMN диаграмм UML [1, 4] является диаграмма
состояний, или последовательности событий, которая представляет собой графическое
представление взаимодействия (interaction) между элементами модели. Взаимодействие
осуществляется в виде обмена сообщениями (messages) между элементами модели с
описанием результата операции. Диаграммы состояний имеют два измерения: по вертикали откладывается время, по горизонтали – различные объекты. Обычно время откладывается сверху вниз диаграммы. В приложениях реального времени ось времени
должна иметь размерность, совпадающую с измерением времени (в секундах, миллисекундах, микросекундах). В горизонтальное расположение объектов модели обычно не
вкладывается какой-то содержательный смысл. Объекты могут группироваться. На диаграммах используются различные виды стрелок, в том числе:
используется для обозначения сигнала вызова или вложен- Стрелка вида
ного потока сигналов управления. При этом вложенный цикл обмена сигналами
управления должен быть завершён до возобновления обмена внешними сигналами.
Стрелка может использоваться в рамках описания обычной процедуры вызова, а
также при обозначениях одновременно активных объектов, когда один из них посылает сигнал и ждёт завершения выполнения вложенной последовательности поведения объекта.
- Стрелка вида
используется для обозначения потоков информации управления
и показывает направление движения событий в последовательности. Обычно все
сообщения, обозначаемые данной стрелкой, являются асинхронными.
- Стрелка вида
обозначает возврат из процедуры вызова.
На рис. 6.11. поступающие вызовы и сигналы управления показаны направленными горизонтальными линиями. Данный рисунок содержит упрощённое описание
процесса внутристанционного соединения между абонентами.
На вертикальной оси отмечено время и описание операций, которые условно показаны горизонтальными стрелками. Сигналы управления обозначены буквами. Функция sendTime (момент времени, когда посылается сигнал или сообщение) и функция
receiveTime (момент времени, когда объект получает сигнал назначения) используются
вместе с условным обозначением сигнала a: b: c: d: для показа времени. Множество
функций времени допускает изменения, так чтобы разработчики могли предлагать новые функции времени, если это необходимо для особых ситуаций или в целях применения модели на практике. Например, в случае коммутации пакетов могут быть предложены функции времени elapsedTime (использованное время), executionStartTime (время
начала выполнения операции), queuedTime (время нахождения в очереди).

Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

Абонент А
{b.receiveTime a.sendTime < 1 сек}
{c.receiveTime b.sendTime < 10 сек}

{d.receiveTime d.sendTime < 5 сек}

a: занятие

151

АТС

Абонент Б

b: зуммер "ответ АТС"

c: набор номера Б

зуммер "контроль
посылки вызова"

d: процесс
установления
входящего
соединения

Время установления
внутристанционного
соединения

зуммер "посылка
вызова"
ответ абонента Б

останов зуммера

останов зуммера

< 1 сек.

Начало времени
разговора

Рис. 6.11 Диаграмма состояний UML
Как правило, диаграмма состояния отображает взаимодействие (interaction) и
обусловленную этими взаимодействиями совместную работу (collaboration) элементов.
Взаимодействие описывает последовательность коммуникационных сообщений между
элементами и содержит совокупность частично ориентированных сообщений
(messages), каждое из которых описывает сигнал связи между элементом-приёмником и
элементом-передатчиком сообщений. Множество объектов при совместной работе могут иметь собственные сигналы взаимодействия.
Для подтверждения сообщений при взаимодействии элементы могут обмениваться координирующими сигналами – стимулами (stimulus). При этом каждый элемент
модели описывается с помощью прямоугольника или условного знака с названием элемента и своей временной вертикальной линией.
Далее использование диаграмм UML рассматривается на примере описания услуги «Аренда линии/канала связи» [16, 18].
6.6.2

Описание требований пользователя

Описание интерфейсов TMN применительно к услуге аренды линии/канала
начинается с описания интерфейса между операционными системами платформы
управления и пользователя [15]. Это необходимо для организации управления арендованной линией со стороны пользователя. Данный интерфейс относится к интерфейсу X,
который обеспечивает двухсторонний обмен между двумя операционными системами;
кроме того, бизнес-требования могут быть адресованы интерфейсам Q внутри системы
управления. В целом поддержка тех или иных услуг управления основывается на соглашении между провайдером услуги или оператором связи, с одной стороны, и пользователем услуги – с другой.
Описание услуги на уровне бизнес-требований должно быть независимо от технических характеристик и свойств сети, которая используется для предоставления услуг. Для управления услугой можно использовать разные технологии, поэтому информация сетевого уровня не должна передаваться на уровень бизнеса. Тем не менее, можно выделить особые свойства услуг, которые позволят предоставить сведения о элементах сети или сети для потребителей услуг. Это относится, например, к данным о длиГлава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

152

тельности неработоспособности арендованной линии, что может повлечь за собой выплату страховки или компенсации ущерба.
Пользователь услуги выполняет роль актора (actor), которая подробно описана в
Рек. МСЭ-Т M.3320 в контексте определения роли TMN для уровня услуг.
Провайдер услуг (service provider) или оператор обозначает сущность, которая
предоставляет телекоммуникационные услуги для пользователя на основе договора или
по назначенному тарифу. Провайдер услуг может быть оператором сети. Кроме того,
провайдер услуг может играть роль «виртуального» оператора, когда он не является непосредственно оператором сети связи, но в то же время предоставляет пользователям
услуги, например услуги по расчёту за аренду. При этом провайдер услуг одновременно
может быть пользователем услуг другого оператора, например оператора магистральной первичной сети. Например, провайдер услуг IP-телефонии может одновременно являться арендатором выделенных цифровых каналов ОАО «Ростелеком».
Услуга аренды линии связи на уровне элемента сети представляет собой оконечное соединение между двумя точками доступа – одна точка доступа на физическом
уровне формируется при подключении оконечного оборудования пользователя к сетевому окончанию; другая точка доступа на физическом уровне формируется как подключение оборудования линейного тракта к коммутационному оборудованию. При
этом подключение в случае выделенной линии не может изменяться после момента начала предоставления услуги. Исключение составляет случай выхода из строя выделенной линии/канала, когда происходит переключение (перекроссировка) на резервную
линию. При описании услуги аренды линии для определения значения параметров услуги и параметров, которые могут быть изменены пользователем в процессе предоставления услуги, используются объекты Service Name (имя услуги) и Service Class (класс
услуги).
В данном случае область управления обозначается как «Управление услугой
аренды линии со стороны пользователя». Актор, выполняющий функции пользователя
услуги, взаимодействует с актором-провайдером услуги с тем, чтобы обеспечивать различные функции управления со стороны пользователя.
Эти совместные действия описываются с использованием групп функций управления, которые даны или в Рек. МСЭ-Т M.3400, или являются заново сформированными
для удовлетворения различных запросов или требований по управлению. Провайдер
услуг может брать на себя роль пользователя услуги, если данная услуга связи сквозная
и предоставляется многими провайдерами.
На рис. 6.12 показан пример использования, где актор-пользователь услуги
взаимодействует с актором-провайдером услуги. При администрирования пользователь
арендуемой линии использует множество функций, которые в целом обозначены в примере использования (use case) «Управление услугой со стороны пользователя»; в свою
очередь, указанный пример использования включает три примера, а именно:
«Предоставление
(обеспечение)
услуги»,
«Управление
неисправностями»,
«Техническая эксплуатация».
Каждый из представленных примеров использования представляет собой множество групп функций, которые далее детализируются в группы функций и окончательно представляются с помощью функций управления. Функции управления в одном
множестве функций примера использования могут расширять функции в другом множестве, чтобы удовлетворить всем требованиям к сервисам управления.
Актор-пользователь услуги взаимодействует с актором-провайдером услуги
прежде всего для выполнения требований примера «Предоставление услуги» (service
provisioning). В свою очередь, этот пример использует два примера использования, не
указанных на рисунке, – множество функций конфигурации услуги «Аренда выделенГлава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

153

ной линии» и множество функций конфигурации выделенной линии.

Управление услугой со
стороны пользователя

Пользователь
услуги

<<include>>

Предоставление услуги
(Service Provisioning)

<<include>>

Оператор связи
(провайдер услуги)

<<include>>

Управление неисправностями
(Trouble Adminisration )

Техническая эксплуатация
(Maintenance)
Источник: МСЭ-Т, Рек. M.3020

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

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

В случае аренды линии классы UML содержат описание предоставления услуги
аренды и соединения/подключения арендованной линии или канала. Класс объектов,
обозначающий пользователя, может генерировать множество запросов на предоставление услуги, как это показано на рис. 6.13, с помощью класса запросов (request), маркированных соответственно как 1 и *. В связи с тем, что существуют одинаковые свойства
услуг «аренда линии» и «соединение линии», основной класс указывается как запрос
услуги (service request).
Пользователь
(Service customer)

Запрос услуги (Service request)
<<mandatory>>provider request
number:Single

0...*

customer name

1...1

0...*
Запрос услуги аренды
(LCS request)

Запрос организации линии
(link service request)

Услуга аренды линии
(LCS)
ServiceID:Single

0...*
Запрос по организации линии
(link service request)
<<frozen>>link connection ID:Single

Рис. 6.13. Диаграмма структуры класса
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

154

Для улучшения восприятия модели для классов указаны не все допустимые операции и атрибуты. Атрибут «запрос номера провайдера» (provider request number) указан здесь без типа. На рис.6.13. видно, что класс «запрос услуги» включает общие элементы для запроса на предоставление услуги аренды линии (LCS request) и запроса на
создание линии (link servise request). Это ясно из содержательного анализа рассматриваемой услуги, например при рассмотрении аренды выделенной линии для подключения к сети Интернет. Здесь запрос на аренду выделенной линии в большинстве случаев
подразумевает необходимость физического создания и подключения выделенной линии
с учётом технических возможностей сети абонентского доступа.
Имя пользователя (сustomer name) является обязательным атрибутом класса
«пользователь услуги» (service customer). Пользователь может получать несколько услуг от провайдера, на что указывается маркировкой 0…*.
Когда услуга предоставлена, например физически организована арендуемая линия, она обозначается с помощью атрибута «идентификатор» или «код услуги» (service
ID). Ограничение «frozen» указывает, что поскольку услуга создана, то значение кода
услуги не может быть изменено в течении жизненного цикла объекта. Это также указывает на то, что идентификатор подключения линии (link connection ID) доступен только
для чтения и не может быть изменен как пользователем, так и провайдером услуги.
Диаграмма состояний для класса «запрос услуги» (service request class) представлена на рис. 6.14.
Получение запроса на
предоставление услуги

приём запроса для обработки

Предобработка
запроса
ожидание
информации

начало обработки

Обработка
запроса
(активная фаза)

постановка на ожидание
передача на выполнение
(активизация)

Незаконченный
запрос
(ожидание)

заверш ение/ошибка

Окончание
запроса

Отмена
запроса

Условные обозначения :
Состояние класса объектов при
обработке запроса

Рис. 6.14. Диаграмма состояний для класса «запрос услуги»
Состояние в UML аналогично состоянию объектов в SDL. Каждое состояние
имеет своё имя, а также список возможных действий класса в данном состоянии. Этот
список на рис. 6.9. не показан. Стрелки указывают направления перехода класса из одного состояния в другое, при этом на каждой стрелке указано действие, которое осущеГлава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

155

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

Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

156

Cписок источников информации к главе 6.
1. Кумсков М. Унифицированный язык моделирования (UML) и его поддержка в
Rational
Rose
98i
CASE-средстве
визуального
моделирования.
[http://www.interface.ru/public/990804/uml4b.htm 5.07.02]
2. Панасенко А.А., Самошкина Н.В., Ерохин А.В. Централизация технического
обслуживания и эксплуатации АТСЦ-90 // Электросвязь. − 2001. − №5. −С. 12 - 14.
3. Построение систем управления сетями связи операторов ВСС РФ. Руководящий документ. – М.: Минсвязи России, 2001.
4. Романовский К.Ю., Кузнецов С.В., Кознов Д.В.. Объектно-ориентированный подход
и диаграммы классов в UML. − ЗАО «Ланит-Терком». – 1999.
5. Шмалько А.В. Цифровые сети связи: основы планирования и построения. – М.: ЭкоТрендз, 2001 г.
6. Baras J., Li H., Mykoniatis G. Technical research report. Integrated, Distributed Fault
Management for Communication Networks. CSHCN T.R. 98-10. (ISR T.R. 98-21) −
Department of Electrical Engineering and Institute for Systems Research University of
Maryland. − 1998. – April.
[bellatrix.isr.umd.edu/TechReports/CSHCN/1998/ CSHCN_TR_98-10/CSHCN_TR_9810.phtml 7.02.01]
7. EN 301 064-1. Telecommunications Management Network (TMN); Information models
and protocols for the management and control of the Asynchronous Transfer Mode (ATM)
switching network element; Part 1: Q3 interface specification. − 1999. − V1.1.2
8. ETSI EN 300 376-1. Telecommunications Management Network (TMN); Q3 interface at
the Access Network (AN) for configuration management of V5 interfaces and associated
user ports; Part 1: Q3 interface specification. − 1999. − V1.2.1
9. ETSI EN 300 378-1. Telecommunications Management Network (TMN); Q3 interface at
the Access Network (AN) for fault and performance management of V5 interfaces and
associated user ports; Part 1: Q3 interface specification. − 1999. − V.1.2.1
10. EN 300 292. Telecommunications Management Network (TMN); Functional specification
of call routing information management on the Operations System/Network Element
(OS/NE) interface. - 1998. − V1.2.1.
11. EURESCOM Project P612. X-Interface for Trouble Ticketing and Freephone Service
Management. Deliverable 2. TMN X interface specifications for trouble ticketing. − Vol. 1
of 5: Introduction and overview. − June, 1998.
[www.eurescom.de/public/projects/ p600-series/P612/P612.HTM 5.06.01]
12. ES 201 654. Telecommunications Management Network (TMN); X interface; SDH path
provisioning and fault management. − June, 1999 – 06. − V1.1.1.
13. EG 201 024. Human Factors (HF); User interface design principles for the
Telecommunications Management Network (TMN) applicable to the "G" Interface. ETSI
Guide. − 1997. − V1.1.1
[http://pda.etsi.org/pda/home.asp?wki_id=3383 12.08.01]
14. EURESCOM Project P609. TMN Specification Support. Deliverable 4. TMN Guidelines
97. Vol. 3 of 7: Annex B - Overview of TMN Interface Specification Concepts. - October
1997.
15. Hellerstein J.L. Automating Performance Management Using Case-Based Reasoning. –
Proceedings of the Computer Measurement Group, 1995.
[http://www.cs.columbia.edu/dcc/classes/E6998-025/projects.html 20.09.01]
16. ITU−T:. TMN interface specification methodology. Recommendation M.3020− 02/2000.
Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

157

17. ITU−T: TMN management services and telecommunications managed areas: overview.
Recommendation M.3200. − 1997.
18. ITU−T: TMN management functions. Recommendation M.3400. − 02/2000.
19. ITU−T: TMN F interface requirements. Recommendation M.3300. − 07/1998.
20. ITU−T: TMN F interface requirements. Recommendation M.3300. Prepublished recommendation. − 07/1998.
21. Lewis D. A Review of Approaches to Developing Service Management Systems.
Department of Computer Science University College London. − 1999.
[http://citeseer.nj.nec.com/lewis00framework.html 19.03.02]
22. Lewis D., Malbon C., DaCruz A. Modelling Management Components for Reuse using
UML/ FlowThru project (AC335). − Department of Computer Science, University College. – London, 1999.
[http://citeseer.nj.nec.com/423455.html 19.03.02]
23. OMG Unified Modeling Language Specification. − Version 1.4, 2001.
[http://www.omg.org/cgi-bin/doc?formal/01-09-67 7.07.02]
24. Petermueller W. J. Q3 Object Models for the Management of Exchanges.//IEEE
Communications. − March, 1996. − Vol. 34, № 3.

Глава 6. Версия 2.

А.Ю.

Гребешков

Стандарты и технологии управления сетями связи

158

7. СОВРЕМЕННЫЕ ПОДХОДЫ И ИНФОРМАЦИОННЫЕ
ТЕХНОЛОГИИ ДЛЯ УПРАВЛЕНИЯ ТЕЛЕКОММУНИКАЦИЯМИ
7.1.
Бизнес−процессы оператора связи и задачи управления
Долгий путь развития телекоммуникационных сетей привел к большому разнообразию применяемых в этой области технологий и оборудования. Огромная протяженность территориальных каналов связи, трудоемкость и высокая стоимость их прокладки и модернизации привели к тому, что все многообразие разработанных технических средств связи все еще «уживается» в одной телекоммуникационной сети: данные,
отправленные абонентом сети общего пользования, могут проходить как через электромеханические коммутаторы, так и через коммутаторы АТМ; медные провода сменяются
в составных системах передачи оптическими волокнами, а технология коммутации каналов сосуществует с коммутацией пакетов и ячеек.
Как уже отмечалось, модель TMN, определенная в Рек. М.3010 МСЭ-Т и других
аналогичных стандартах, представляет собой систему взглядов на технологическое
управление неоднородной телекоммуникационной сетью, построенной на различных
технологиях, типах оборудования и программного обеспечения. Стандарты, предлагаемые МСЭ-Т, в основном сконцентрированы на уровне элемента сети и управления сетями. Фактически рекомендации МСЭ-Т были разработаны «снизу вверх» [4]. Этот
подход вызвал определённые затруднения уже на этапе определения экономической
эффективности применения систем сетевого управления. У операторов электросвязи
вызывает существенные затруднения вопросы определения экономической эффективности и целесообразности применения систем сетевого управления. Это весьма важный
вопрос, так как начальная стоимость предлагаемых решений по управлению достаточно
высока. По данным компании Hewlett Packard (газета PC WEEK №29-30 от 20.08.02),
начальная цена решения на базе платформы управления телекоммуникационными сетями голосовой связи Compaq TeMIP составляет 350 000 долларов, а для крупных сетей
связи она может достичь 1–3 миллионов долларов США.
Кроме того, подход «снизу вверх» не учитывает всей сложности бизнес−задач
оператора связи, связанных с предоставлением/продажей услуг связи, гарантиями качества услуг, продаж услуг и т.п. И это несмотря на то, что все перечисленные процессы
прямо или косвенно нуждаются в едином управлении, которое должно быть взаимоувязано с «технологическим» управлением оборудованием и средствами связи по стандартам TMN.
Для разрешения сложившейся ситуации начиная с 1995 г. неправительственная
организация Форум сетевого управления (TeleManagement Forum, TMF) разрабатывает
систему взглядов на проблемы сетевого управления по принципу «сверху вниз», используя современные информационные технологии и модели бизнес−процессов для
разработки рекомендаций операторам связи по использованию сетевого упралвения для
решение не только эксплуатационных, но и бизнес-проблем, возникающих в процессе
телекоммуникационного бизнеса.
Подготовленные в последние 5..7 лет руководства и технические отчёты TMF
являются в настоящее время стандартами de−facto в части современных подходов к сетевому (и не только сетевому) управлению [15,18,28].
Для упорядочения изложения разработанных решений и стандартов в настоящей
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

159

главе в первую очередь рассматриваются бизнес−процессы оператора связи как объекты управления высшего уровня. Далее приводятся базовые бизнес− и технологические
решения по управлению, рассматриваются информационные технологии для управления и, наконец, даётся общее описание продуктов, позволяющих реализовать современные подходы и принципы сетевого управления.
Итак, в первую очередь необходимо дать определение бизнес−процесса как нового объекта управления в телекоммуникациях.
«Бизнес−процесс − это множество внутренних шагов (видов) деятельности, начинающихся с одного или более входов и заканчивающихся созданием продукции, необходимой клиенту. Назначение каждого бизнес−процесса состоит в том, чтобы предложить клиенту товар или услугу ... удовлетворяющую его по стоимости, долговечности, сервису и качеству» [5, с. 17].
Существуют внешние и внутренние бизнес−процессы компании связи. Внешние
бизнес−процессы определяют взаимодействие компании связи с другими участниками
бизнеса телекоммуникаций. Характерным здесь является то, что набор действий, который осуществляет компания связи, должен быть структурирован, измеряем [5, с. 124] и
иметь конкретный выход для клиента. В этом контексте контроль за непрерывностью
связи предусматривает, к примеру, мониторинг состояния систем связи с обусловленной дискретностью во времени, резервирование оборудования/линий/каналов по различным схемам, организацию обходных направлений и своевременное проведение аварийно−восстановительных и планово−предупредительных работ. Каждое из перечисленных здесь действий включает определённую совокупность процедур технического
обслуживания и эксплуатации со строго определёнными временными границами.
Внутренние бизнес−процессы представляют собой декомпозицию внешних бизнес−процессов на внутренние процессы компании связи, которые позволяют получить
требуемый результат для пользователей услуг.
Каждый процесс должен «уметь» принимать входные данные, совершать над
ними определённые операции, использовать при осуществлении операции различные
ресурсы (человеческие, информационные, вычислительные) и данные, формировать
решение и выдавать определённые сведения на «выходе». Для обработки данных в каждом процессе имеются соответствующие функции, т.е. составные части процессов.
Функция − это определённая сущность, выполняющая заданную операцию по
обработке входной информации. После завершения работы той или иной функции на
выходе появляется определённая информация, которая используется в качестве входной
другой функцией. Функции инициализируются внешним событием, например результатом выполнения предыдущего процесса (рис. 7.1).
Для описания динамики бизнес−процесса используют понятие “поток событий”
[13], т.е. последовательность взаимосвязанных процессов (и составляющих функций).
Например, при регистрации нового клиента компании электросвязи необходимо не
только правильно ввести фамилию, имя, отчество, адрес регистрации, паспортные данные, информацию о технической возможности оказания услуги связи, но и проверить
сведения о возможных прошлых долгах по оплате услуг электросвязи. Потоки событий
описываются с помощью прецедентов, в качестве которых выступает последовательность определённых операций (транзакций, функций), которые направлены на получение какой−то потребительской ценности, например на предоставление услуги связи по
запросу клиента.

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

160

К функции n-й

Да

Триггер

Процесс i
Нет

Данны е на
входе от
процесса i-1

Данные на
выходе

Функция 1

Данные

Функция 2

Данны е

Рис. 7.1 Структурная схема взаимодействия процесса, функций и данных
В дополнение к описанному механизму на рис. 7.1 изображены триггеры
(triggers) и элементы контроля завершения выполнения функций (решающая схема).
Эти элементы предназначены для синхронизации выполнения процессов, при этом изменение состояния триггера отмечает начало/завершение выполнения процесса, а решающий блок управляет последовательностью выполнения функций в процессе, т.е.
фактически создаёт определённый прецедент.
Все участники телекоммуникационного бизнеса в рамках тех или иных отношений/прецедентов являются субъектами, т.е. выполняют ту или иную роль. Например,
компания − провайдер услуг Интернет по отношению к пользователю выполняет роль
провайдера услуги, а по отношению к оператору связи - арендатора номерной ёмкости
и каналов связи/выделенных линий. Причём и провайдер, и оператор связи находятся в
рамках одной бизнес−системы.
Различают внешнюю и внутреннюю модель бизнес−процессов для компании
связи. Внешняя модель описывает взаимоотношения данной компании связи с клиентом
и другими компаниями связи. Здесь чрезвычайно важна детальная проработка интерфейса между клиентом и процессом компании. Внутренняя модель соответственно
предназначена для описания того, из каких внутренних процессов (рабочих задач) состоит бизнес−процесс компании.
Задачи управления являются ключевыми как во внешней, так и во внутренней
модели. Как следует из вышесказанного, задачи управления сетью связи на современном этапе рассматриваются не только в контексте сетевого управления, но в первую
очередь как задачи управления услугами связи и бизнес−процессами оператора. В дальнейшем изложении задачи управления бизнесом рассматриваются только в связи с предоставлением услуг связи; управление акционерным капиталом, способы привлечения
финансовых средств, стратегические направления инвестиций детально не обсуждается,
так как находится за рамками темы данной книги.
Итак, в рамках как внутренней, так и внешней бизнес−модели каждый процесс
состоит из определённого набора функций. При этом процессы объединяются потоком
событий в соответствии с тем или иным прецедентом. Данное положение рассматривается детально в рамках документа [18], сокращённо именуемого eTOM. Документ
eTOM базируется на Telecom Operations Map (технологическая схема сетевой эксплуатации [4], или технологическая схема сетевых операций [3]. Второй перевод в контексте
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

161

рассматриваемых документов представляется более точным. – А.Г.). eTOM расширяет
определённые положения TOM в направлении общей производственной схемы предприятия связи и тех изменений, которые происходят с учетом влияния электронного
бизнеса (e−business). Большинство положений eTOM получены путём обобщения практического опыта многих провайдеров и операторов связи, что ценно само по себе. При
этом впервые бизнес−процессы сервис−провайдеров объединены в рамках одной модели с бизнес−процессами операторов электросвязи, что в конечном счёте привело к обновлению TOM до уровня eTOM.
Целью документа eTOM является дальнейшее развитие индустриального подхода для успешной конкуренции с помощью внедрения бизнес−процессов для управления
предприятиями связи. Эта концепция включает в себя интеграцию всех жизненно важных для предприятия связи систем поддержки, основное назначение которых состоит в
предоставлении и обеспечении услуг связи.

7.2

Схема бизнес-процессов оператора связи

В центре внимания документа eTOM находятся бизнес−процессы, используемые
сервис−провайдерами (операторами связи), связи между этим процессами, идентификация необходимых интерфейсов и использование информации пользователя (customer),
услуги (service), ресурса (resource), поставщика/партнёра (supplier/partner) многими
процессами.
Перечисленные понятия были введены в документе Telecom Network Operation
Map версии 2000 г., а также включены в приложение к eTOM. Наиболее важные понятия, необходимые для понимания новых задач управления, выглядят следующим образом:
• пользователем считается субъект, использующий услуги, предоставляемые провайдером;
• провайдер, или сервис−провайдер − это компания или фирма, основной бизнес которого состоит в предоставлении телекоммуникационных услуг/услуг электросвязи;
• оператор − это организация или компания, которая использует телекоммуникационную инфраструктуру. Оператор также может быть провайдером, что характерно
для базовых услуг связи (местная и междугородная телефония, услуги документальной электросвязи);
• услуга − разрабатывается сервис−провайдером для продажи в составе продуктов.
Одни и те же услуги могут включаться в несколько продуктов, но в различном сочетании;
• ресурс − представляет собой физический или нефизический компонент, используемый при создании услуги, и включает элементы сети, программное обеспечение,
информационные системы и технологические компоненты;
• поставщик/партнёр − компания или организация связи, предоставляющая свои услуги или продающая товары/продукты оператору связи;
• процесс − описывает систематизированное последовательное множество функциональных действий (функций), которые завершаются определённым результатом или
выходными данными.
Здесь следует оговориться, что в рамках современного представления о бизнес−процессах под продуктом (product) в телекоммуникациях понимается потребительская ценность, которую сервис−провайдер предлагает клиентам или пользователям. В
свою очередь услуга или сервис (service) отражает элементы и детали предоставления и
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

162

поддержки продукта для пользователя.
В настоящее время критически важным для деятельности оператора связи и сервис−провайдера является автоматизация бизнес−процессов. Поэтому документ eTOM
включает в себя описание схемы бизнес−процессов оператора связи (eTOM business
process framework), а именно:
• собственно индустриальные бизнес−процессы сервис−провайдера;
• общие определения для описания схемы бизнес−процессов;
• соглашения о том, какая базовая информация требуется для осуществления процесса, подпроцесса. Указанное описание также называется «описанием данных высокого уровня» и требуется в качестве исходных данных для разработки бизнес−требований к системе управления и информационной модели;
• схема процессов с указанием, какие процессы и интерфейсы в наибольшей степени
требуют автоматизации и взаимоувязки, также зависит от индустриальных соглашений производителей.
В целом общее представление схем бизнес−процессов в документе eTOM представлено на рис. 7.2.

Пользователи

Стратегия развития,
инфраструктура,
используемое
обрудование и
продукты

услуг связи

Эксплуатация / сетевые
операции

Рынок, продукты/услуги и клиенты

Услуги связи

Ресурсы (сетевые, вычислительные, прикладное ПО)

Партнёры/поставщики

Управление компанией связи в целом
( управление персоналом, взаимоотношения с акционерами,партнёрами)

Рис. 7.2. Уровень 0 представления схемы бизнес−процессов оператора связи
На этом рисунке показан так называемый уровень 0 представления схем бизнес−процессов (eTOM business process framework − level 0 process). Эта схема демонстрирует самое общее представление процессов оператора связи. При этом все процессы
поделены на две общие (вертикальные) группы: в первой группе сосредоточены процессы, определяющие стратегию развития оператора, его инфраструктуры и используемые продукты, т.е. фактически жизненный цикл оператора; во второй находятся сетевые операции, которые осуществляет оператор или сервис−провайдер.
По горизонтали, в виде четырёх уровней, представлены функциональные области, которые включают функции, обеспечивающие выполнение бизнес−процессов от
момента начала стратегического планирования до расчётов за предоставленные услуги.
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

163

Здесь же указаны другие элементы, оказывающие непосредственное воздействие на
бизнес−процессы оператора связи: управление производством, акционеры, персонал,
поставщики услуг для оператора, партнёры.
Разделение на вертикальные группы и горизонтальные уровни логически объяснимо, так как успешное завершение процесса обслуживания абонента может зависеть
как от типа и возможностей установленного оборудования связи (что обусловлено планированием, выбором поставщика, задействованными ресурсами), так и от используемых оператором технологических операций, например, процедур технической эксплуатации, регламента использования средств связи.
Уточняя общие положения по моделированию бизнес−процессов, изложенные
выше, eTOM описывает процессы и точки взаимодействия процессов, которые составляют законченные потоки процессов пользователей для выполнения процедуры предоставления услуги (fulfillment), гарантии качества услуги (assurance), учёта использования
и расчёта за предоставление услуг связи (billing). Каждый из перечисленных разделов в
свою очередь состоит из законченных цепочек процессов. При этом eTOM в первую
очередь рассматривает процессы, которые являются специфическими для информационных и коммуникационных услуг и технологий управления.
Декомпозиция бизнес−процессов полезна как для операторов связи, так и для
сервис−провайдеров, поскольку позволяет сделать бизнес более эффективным, упорядочить собственные технологические процессы, успешно применять программное
обеспечение, разработанное третьей стороной, без затрат на существенную адаптацию.
При этом рекомендации eTOM относятся прежде всего к бизнесу традиционных операторов связи с возможным расширением решений для электронного бизнеса.
Процессы, описанные в eTOM, не относятся к бизнес−модели сервис−провайдера или оператора связи, о чём также говорится в [4]. В eTOM не рассматриваются вопросы о целевой группе клиентов, на которую ориентируется сервис−провайдер, о сегменте рынка, в котором будет работать оператор связи, нет описания миссии сервис−провайдера, программы предоставления услуг, оценки стоимости
услуг, описания схем финансирования телекоммуникационных проектов. Схема
бизнес−процессов относится прежде всего к стратегической модели бизнеса сервис−провайдера. Данное
описание бизнес−процессов способствует бизнес−реинжинирингу деятельности оператора в меняющихся условиях рынка. Модели
высшего уровня, как правило, не имеют особой практической ценности для многих
участников рынка телекоммуникаций и сотрудников среднего звена администраций
связи, поэтому в документе eTOM разработаны процессы низшего уровня. Результат
частично демонстрируется на рис. 7.3. Здесь показан уровень 1, включающий взаимосвязи основных процессов. Хотя на таком уровне детализации показана точка зрения на
бизнес высших руководителей компании. В настоящее время каждый из процессов на
рис. 7.3 разбит на более детальные процессы (уровень 2), с которыми собственно и имеет дело подавляющее большинство сотрудников компаний связи и провайдеров. Пример такого разбиения будет показан ниже.
На рис. 7.3 показаны семь групп процессов, сгруппированных по вертикали. Это
сквозные (end−to−end) процессы, которые охватывают несколько функций и требуются
для поддержки пользователей услуг и для управления бизнесом оператора связи. С этой
точки зрения центральными здесь являются процессы эксплуатационной поддержки/сетевые операции пользователей (customer operations processes), которые объединены
под общей аббревиатурой FAB (Fulfillment, Assurance, Billing). При этом процессы
обеспечения или поддержки эксплуатации и готовности систем связи (operations support
& readiness) функционально отделены от FAB. Это вызвано тем, что процессы, составГлава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

164

ляющие FAB, происходят в реальном времени, и описываемое функциональное разделение подчёркивает необходимость автоматизации процессов FAB для постоянной и
своевременной поддержки пользователей. Процессы FAB имеют прямые интерфейсы с
пользователями услуг связи и находятся в центре производственной деятельности оператора связи.
Стратегия развития (strategy & commit), управление жизненным циклом инфраструктуры (infrastructure lifecycle management) и управление жизненным циклом продуктов
(product lifecycle management) функционально разделены. Они, в отличии от сетевых
операций, не связаны с непосредственной поддержкой пользователей и функционируют
в другом масштабе времени. Для создания инфраструктуры телекоммуникаций, строительства зданий и сооружений требуются годы, в то время как для проверки состояния
счёта пользователя перед установлением сеанса связи требуются секунды. На рис. 7.3
выражение «жизненный цикл» опущено. Это понятие означает, что управление осуществляется от момента начала строительства инфраструктуры или введения новой услуги до момента демонтажа сети и прекращения действия услуги связи.
Пользователи
Стратегия развития, инф раструктура,
используемое обрудование и продукты
(SIP)
Стратегия
Управление
Управление
развития
инф раструкпродуктами и
турой
услугами

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

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

услуг связи

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

Предоставление услуги
( F ulfilm ent)

Обеспечение
услуги
( A ssurance)

Расчёт за
услугу
( B illing)

Управление взаимоотношениями с пользователями
Сетевая эксплуатация и управление услугами
Сетевая эксплуатация и управление ресурсами
Управление взаимоотношениями с партнёрами и
поставщиками

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

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

Рис. 7.3 Уровень 1 представления схемы бизнес−процессов оператора связи
В частности, для успешного предоставления услуги связи необходимо (сверху
вниз по горизонтальным уровням):
• работать с потенциальным пользователем (управление взаимоотношениями с
пользователем);
• организовать техническую возможность предоставления услуги на оборудовании связи, например обновить программное обеспечение (сетевая эксплуатация и управление услугами);
• своевременно проводить планово-предупредительные и регламентные работы на оборудовании для поддержания качества услуги (сетевая эксплуатация
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

165

и управление ресурсами);
• организовать взаимодействие с третьей стороной, например с ОАО «Ростелеком» или ОАО «Транстелеком» (управление взаимоотношениями с партнёрами и поставщиками).
Причём те же перечисленные функции надо осуществлять и при обеспечении услуги, и при расчётах за услуги связи.
Управление инфраструктурой и управление продуктами и услугами представляют собой основу стратегического развития оператора. Очевидно, что без плана капитального строительства, схем развития сетей связи, планов ввода емкости ни один оператор не может нормально реализовать свои бизнес−планы. Сюда же относится планирование предоставления новых услуг, таких как Интернет, IP−телефония и т.п. Все эти
вопросы объединяются в рамках стратегии развития оператора связи.
Процессы SIP необходимы для того, чтобы гарантировать, что сетевые процессы
пользователя (customer оperations processes) полностью отвечают требованиям клиента,
в том числе в части сроков предоставления, стоимости, уровня поддержки и доступности услуги. Например, развитие системы сигнализации ОКС№7 как стратегическое направление совершенствования инфраструктуры сделало возможным предоставление
услуги междугородной видеоконференцсвязи по технологии ЦСИС (только цифровизации магистральной первичной сети было недостаточно). Процессы SIP не имеют прямых интерфейсов с пользователями услуг связи, хотя и критически важны для производственной деятельности предприятия связи в целом.
Особо надо отметить процессы, связанные с разработкой и управлением цепочками поставок (supply chain management). Эти процессы особенно важны для электронного бизнеса, а также в случае поставок продуктов и услуг со стороны других операторов и партнёров. Например, в случае крупных культурных или спортивных событий,
репортажи о которых транслируются в сети Интернет в режиме on−line, провайдер услуг Интернет может заказать у оператора связи увеличение полосы пропускания на магистральном канале согласно времени трансляции с места события.
Даже в самом общем виде схема бизнес−процессов является полезной не только
для операторов или сервис−провайдеров, но и для разработчиков и интеграторов программного обеспечения для систем бизнес−поддержки операторов связи (Business Support System, BSS) и систем эксплуатационной поддержки операторов связи (Operations
Support System, OSS) [17,19]. Подробнее OSS будут рассмотрены в разделе 7.6.
Предлагаемая схема позволяет оператору связи или сервис−провайдеру отойти
от ориентации только на предоставление услуг или пресловутой «заботы об абоненте» в
пользу управления взаимоотношениями с пользователями. Это позволяет делегировать
ряд полномочий по управлению оконечного оборудования пользователю или партнёру,
внедрять сетевое управление и контроль со стороны пользователей, повышая таким образом долю и уровень участия клиентов в деятельности предприятий связи. О некоторых аспектах такого участия будет рассказано в дальнейшем при рассмотрении описания взаимодействия пользователь−оператор при аренде выделенной линии связи.
В заключение представим дальнейшую проработку бизнес−процессов на рис.
7.3. Для примера рассмотрим группу «Предоставление услуги (fulfillment)» с точки зрения функции «Управление взаимоотношениями с пользователями». Точка пересечения
указанная группа функций может быть разделена пять составляющих процесса 2−го
уровня (Level 2), представленных на рис. 7.4.

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

166

Эксплуатация / сетевые
операции
Предоставление
услуги

Управление
взаимоотношениями с
пользователями

Управление
интерфейсом
пользователя

Реакция на
маркетинг
услуги

Продажа
услуги

Обработка
заказа услуги

Удержание
пользователя

Рис. 7.4 Уровень 2 схемы бизнес−процессов оператора связи
Представленное здесь разбиение бизнес−процессов уровня 2 не является конечным. Каждый оператор или сервис−провайдер может разделить, например, процесс
«Продажа услуг» ещё на ряд подпроцессов. Однако такая детализация затрагивает уже
проблемы организации бизнеса, специфические для каждого оператора, и детально не
рассматривается.

7.3

Технологическая схема сетевого управления и эксплуатации

Как уже отмечалось выше, подход TMF состоит в том, чтобы, используя ориентированность на бизнес−процессы и предоставление услуг для конечных пользователей,
достичь сквозной автоматизации процессов оператора, используя готовое программное
обеспечение от различных поставщиков. Для достижения указанной цели, TMF предлагает интегрированный подходы к проблемам организации и управления процессами
оператора или сервис−провайдера, увязывая тем самым разнообразные международные
и национальные стандарты. При этом используется принцип «сверху вниз», т.е. развитие стандартов построения сетевого управления осуществляется от основных сетевых
процессов (в том числе эксплуатации) по направлению к оборудованию связи.
Для реализации на практике такого подхода TMF разрабатывает многочисленные руководства, которые включают прежде всего описание, обобщение и разбиение
процессов оператора связи с описанием данных и функций, необходимых для работы
оператора. При этом основой для построения моделей TMF являются рассмотренные в
главе 3 основные положения концепции TMN, в частности функциональная и логическая архитектура TMN.
В этом плане важным этапом является разработка в 2000 г. схемы под названием
Telecom Operation Map (ТОМ), которая во многом стала основой для eTOM, рассмотренной в разделе 7.2. При этом TOM версии 2000 г. представляет прежде всего интерес
для специалистов по эксплуатации и работе с абонентами (рис. 7.5).
Фактически на рис. 7.5 изображена детальная версия правой части схемы на рис.
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

167

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

услуг связи

Предоставление услуги
Продажи
услуг

Обработка
заказов на
услугу

Обеспечение услуги
Обработка
проблем с
предоставлением услуг

Управление
QoS
пользователя

Биллинг
Вы ставление
счетов и сбор
оплат за
услуги

Процессы поддержки пользователя
Планирование и
разработка
услуги

Конфигурация услуги

Разрешение
проблем с
услугами

Управление
качеством
услуги

Начисления и
скидки на
оплату услуг

Процессы разработки и эксплуатации услуг и продуктов
Планирование и
развитие
сетей

Обеспечение
сетей для их
функционирования

Управление
техническим
учётом

Эксплуатация
и восстановление сетей

Управление
данны ми
сети

Процессы управления сетью и системами

Процессы упралвения информационными
системами

Процесс управления интерфейсом пользователя

Физическая сеть и информационные технологии

Рис. 7.5. Технологическая схема сетевых процессов оператора
Целью сервис−провайдеров является автоматизация процессов для того, чтобы
предоставить потребительскую ценность пользователям. Следовательно, наиболее критические процессы предоставления услуг разрабатываются и описываются как сквозные
потоки процессов. TOM предлагает три группы процессов, общих для любого телекоммуникационного бизнеса, ориентированного на предоставление услуги:
• предоставление услуги (service fulfillment), т.е. корректное по времени и объёму предоставление той потребительской ценности, которую заказал пользователь;
• обеспечение услуги (эксплуатация и техническая поддержка услуг, в частности, своевременное обнаружение и распознавание инициированных проблем
пользователя, отслеживание проблем, генерация сообщения о проблемах, в
том числе журналирование, управление и принятие мер для улучшения характеристик услуг во всех аспектах);
• биллинг услуг, т.е. своевременная подготовка точного счёта, всесторонняя и
всеобъемлющая информация при запросе счёта клиентом, включая своевременное исправление счетов при обработке и сбор информации об осуществлённых оплатах.
Вертикальные секции на рис. 7.5 представляют собой взаимодействие между интерфейсом пользователя и сетевым элементом, т.е. сквозной поток процессов. Разумеется, все сквозные процессы имеют «внутри» множество интерфейсов между собой; это,
как правило, прикладные программные интерфейсы. Доминирующим здесь является
процесс предоставления услуги. Далее процесс обеспечения услуги может быть запуГлава 7. Версия 2.0
А.Ю.Гребешков

Стандарты и технологии управления сетями связи

168

щен со стороны пользователя или элемента сети. К примеру, абонент может активизировать ту или иную услугу с абонентского устройства, или услуга активизируется программным обеспечением автоматически по заранее составленному расписанию. Биллинг обусловлен наличием данных на сети, достаточных для подготовки счёта пользователю.
По горизонтали, как отмечалось в разделе 7.2, расположены последовательные
процессы, интерфейсы между которыми соответствуют интерфейсам с другими операторами связи или с сервис−провайдерами.
Следует отметить, что граница между двумя группами процессов может «разрезать» определённые процессы. Например, для обеспечения услуги связи и для биллинга
необходимо управление данными сети. Это управление данными предусматривает наличие интерфейсов с элементами сети для сбора данных.
Сравнивая схему на рис. 7.5 со стандартизованными МСЭ−Т уровнями управления можно отметить, что предложенная схема соответствует прежде всего уровню
управления услугами и, частично, уровню управления сетью связи. При этом стандартный уровень управления услугами поделен на две части: процессы поддержки пользователя (customer care) и уровень разработки и эксплуатации услуг и продуктов (service
development and operations processes). Это достаточно простое разделение указывает на
различие между процессами, которые осуществляются для индивидуального пользователя, и процессами, которые требуются для групп пользователей при массовом предоставлении услуг. Кроме того, указанное разделение подчёркивает необходимость определения в автоматическом режиме объёма услуг связи, предоставленных пользователю
при условии прямого контакта с ним.
Управление интерфейсом пользователя в данной схеме приобретает особое значение, так как именно с его помощью осуществляются процессы поддержки клиента.
По этой причине в рассматриваемой схеме процессы управления интерфейсом выделены в отдельный уровень. В частности, на данном уровне могут предоставляться услуги
обработки и распределения вызовов от пользователей, услуги контакт−центра для технической поддержки клиентов, системы распознавания голоса и т.п. [7].
Описываемая схема не зависит от вида организации связи, используемой сетевой
и информационной технологии, оказываемых услуг связи. Схема сохраняет свою актуальность и состоятельность при вводе новых услуг связи и появлении новых телекоммуникационных технологий. Однако при вводе управления некоторыми новыми услугами, например управления роумингом в сетях подвижной связи, могут быть сформированы новые бизнес− и функциональные требования к описанным выше процессам.
В заключение рассмотрим подробнее самый нижний уровень детализации описываемых процессов на примере составляющей процесса биллинга − формирование
счетов на оплату услуг связи и сбор оплат. Этот процесс во взаимосвязи с другими процессами показан на рис. 7.6.
Процесс биллинга услуг связи начинается с момента создания и обновления лицевого счёта пользователя согласно условий соглашения об уровне обслуживания (Service Agreement Level, SLA) для данного пользователя [8]. В Российской Федерации
функции такого соглашения выполняет договор на оказание услуг связи и приложения к
договору.
На рис. 7.6. показана типичная последовательность выполнения функций подготовки счёта на оплату услуг связи, включая такие элементы как ежемесячные начисления за услуги связи, тарификация данных об использовании сети связи пользователем и
возможные нарушения SLA (например, время неработоспособности абонентского устройства не по вине абонента). Сбор данных предусматривает непосредственное считыГлава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

169

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

Предоставление услуги
Обработка
заказов на
услугу

Обеспечение
услуги
Обработка
проблем с
предоставлением услуг

Активизация
счёта
пользователя

Скидки

Выставление
счетов и сбор
денежных
средств

Сумма счёта
пользователя

Нарушения
SLA

Сбор оплат
Выставление счетов

Начисления
Начисления и
скидки на услуги
связи

Агрегированные
данные об
использовании
сети
Управление
данными сети
Данные об
использовании сети
при оказании услуг
связи

Генерация счёта
пользователю

Пользователь :
запрос на счёт
и оплата

Скидки

Агрегирование
Сортировка
Сбор данны х

Сетевы е элементы и управление
сетевыми элементами

Другой оператор
или
сервис-провайдер

Обозначения :
Взаимодействие
между уровнями
Взаимодействие
между группами FAB
Взаимодействие c
внешними системами
Функции

Рис. 7.6 Схема информационного взаимодействия в рамках TOM для процесса
биллинга услуг связи
Начисления представляют собой функцию расчёта конечной стоимости услуги,
включая налоги и скидки. Наконец, конечные суммы счёта проставляются в поля соответствующего бланка по видам услуг и передаются пользователю по его запросу или в
обусловленные периоды времени. Счёт передаётся пользователю в бумажном или электронном виде.
Если услуга предоставляется несколькими сервис−провайдерами, то, как показано на рис. 7.6, данные об использовании сети при оказании услуг связи могут агрегироваться «основным» сервис−провайдером на основании сведений от «вторичных» провайдеров, в результате чего пользователю выставляется единый счёт на оплату услуг
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

170

связи. Разумеется, тот или иной порядок действий определяется используемой технологией расчётов, пожеланиями пользователя, возможностями сервис−провайдера. В документе [13] подобные схемы составлены для всех процессов технологической карты сетевых процессов оператора связи.
В контексте данной книги интерес представляют процессы управления сетью
связи и системами. Назначение этих процессов состоит в том, чтобы обеспечить необходимую поддержку предоставлению услуг связи со стороны сетевой инфраструктуры
и информационных технологий, используемых оператором связи. Практическая реализация процессов заключается в том, чтобы обеспечить требуемую инфраструктуру для
предоставления услуги связи, гарантировать непрерывное функционирование инфраструктуры, сделать услуги доступными пользователю, осуществлять техническую эксплуатацию инфраструктуры для обеспечения требуемого качества продуктов и услуг
связи. Уровень «Процессы управления сетью и системами» представляет собой интегральный уровень, объединяющий уровень управления сетевым элементом и уровень
управления сетью связи. Базовые функции рассматриваемых процессов (см. рис. 7.1)
состоят в том, чтобы:
• собирать информацию управления от системы управления элементами сети;
• объединять собранную информацию;
• устанавливать корреляционные связи (например, определять первичные источники
повреждений и сопутствующие сообщения о неисправностях);
• суммировать собранную информацию и посылать её на высшие уровни, в частности
на уровень управления услугами связи.
Управление сетью, безусловно, не только выполняет функцию передачи сведений от элементов сети на уровень управления услугами. Управление сетью имеет важные собственные задачи, такие как планирование сети, обеспечение сети, управление
техническим учётом, эксплуатация.
Планирование и развитие сетей связи (network planning and development) означает полное обеспечение существующей инфраструктуры сетей. В российских стандартах
эти процессы заключаются в разработке генеральных схем развития сетей связи.
Обеспечение сетей (network provisioning) означает создание инфраструктуры,
т.е. капитальное строительство сооружений связи, проведение реконструкции, технического перевооружения и расширения оборудования и систем связи.
Управление техническим учётом (network inventory management) предусматривает ввод в работу элементов сети, администрирование элементами физической сети и
учёт характеристик элементов.
Эксплуатация сети и восстановление предусматривает проведение работ по
обеспечению доступности сети и эксплуатации инфраструктуры. Управление данными
сети предусматривает сбор данных для управления сетью и предоставление записей для
расчётов с пользователем за услуги связи (данные для биллинга). Важно отметить, что
возможности по управлению сетями сосредоточены именно на том уровне, где существует возможность получения данных непосредственно от элементов сети (например,
через интерфейс Q) вместо того, чтобы передавать функции сетевого управления на
уровень управления услугами связи.

7.4

Управление в среде распределённых вычислений

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

7.4.1

171

Модель распределённой системы обработки данных

В 1960 − 1980 гг. управление сетями связи рассматривалось в рамках телеметрии, при которой элементы сети посылали поток автономных сообщений о своём состоянии на центр управления. Позднее такие протоколы управления, как SNMP и CMIP,
использовали архитектуру «агент − менеджер». Этот подход позволил обеспечить взаимодействие между центром управления и оборудованием связи. C помощью передачи и
выполнения тех или иных команд стало возможным осуществлять на удалённых объектах определённые операции управления. Тем не менее, применение данного подхода не
было лишено недостатков [12,14].
Основные недостатки разработанных в рамках концепции TMN информационной
и вычислительной моделей управления:
• программное обеспечение менеджера или агента может функционировать на
одном управляющем устройстве не может состоять из элементов, распределенных по нескольким сетевым узлам;
• информационная модель управляемого объекта ориентирована на поддержку
прежде всего протокола CMIP и зачастую не может поддерживать взаимодействие в другой среде;
• недостаточно развиты инструментальные средства проектирования систем
управления.
В период с 1995 г. МСЭ−Т и ISO/IEC опубликовали рекомендации серии Х.900,
содержащие определения эталонной модели для открытой распределенной обработки
данных (Open Distributed Processing, ODP). Эта модель согласована с CORBA (см. раздел 7.6) и предназначена для организации взаимодействий между распределенными
процессами в гетерогенных сетях. Архитектура управления ODP- системами была
опубликована в Рек. Х.903 и получила наименование «открытая архитектура распределённого управления» (Open Distributed Management Architecture, ODMA).
Отличительной особенностью распределённых систем является высокая степень
модульности и децентрализации. Модульность на практике означает множество компонент, из которых состоит распределённая система. Главный компонент отсутствует. Для
компонентов важно организовать интерфейсы взаимодействия. Интерфейсы взаимодействия и координацию работы компонент в целом осуществляет промежуточный слой.
На транспортном уровне постоянную связь между компонентами поддерживает сеть
передачи данных. Физически компоненты реализуются в виде программных приложений, написанных на различных языках программирования.
Общая модель распределённой среды представлена на рис. 7.7. Пользователи воспринимают распределённую систему как единую вычислительную среду. Другими словами, распределённая среда должна быть прозрачная для пользователей.

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

172

Компонент 1

...

Компонент n

Промежуточный слой
Операционная система

Компонент 1

...

Медиатор

Компонент n

Промежуточный слой

Компонент 1

Операционная система
Медиатор

Сеть передачи
данны х

...

Компонент n

Промежуточный слой
Операционная система
Медиатор

Рис. 7.8 Модель распределённой системы
Существуют три категории промежуточного слоя [11]:
• транзакционно ориентированная (применяется в распределённых СУБД);
• ориентированная на посылку сообщений (поддерживает асинхронную передачу и групповую рассылку сообщений; сообщения могут храниться в очереди);
• объекто−ориентированная (реализована в CORBA).
ODMA предназначена для спецификации и разработки системы управления, которая может представлять собой открытое распределенное приложение и содержит архитектурные базовые принципы, необходимые для разработки последующих стандартов в рамках этой архитектуры. Общие базовые принципы ODMA определяют обобщенную модель управления, которая обеспечивает интеграцию систем управления, построенных как на базе стандартов управления ВОС, так и на базе архитектуры CORBA,
модели управления Интернетом и других моделей управления распределенными объектами и компонентами программного обеспечения. Стандарты на средства поддержки
ODMA в различных моделях управления, таких как модели OSI или CORBA, определяют отображения этих моделей управления в эталонную модель ODMA
В настоящее время в информационной индустрии применяется технология распределённых вычислений, которая базируется на распределённых системах. В этой связи наиболее значительными распределёнными технологиями являются [10,19]:
• общая архитектура брокера объектных запросов (Common Object Request
Broker Architecture, CORBA) предложенная Object Management Group (OMG);
• технология удалённого вызова методов (Java Remote Method Invocation, Java
RMI), предложенная Sun Microsystems;
• объектная модель компонентов (Microsoft Distributed Common Object Model,
DCOM), которая сейчас известна под маркой COM+.
Поскольку распределённые объектные технологии оказывают существенное
влияние на рынок приложений управления, в настоящем и в следующем разделах рассматриваются возможные решения в части управления телекоммуникациями с использованием новых подходов.

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

7.4.2

173

Блоки построения в трёхуровневой модели INA

В начале 1990−х гг. компания Telcordia Technologies (бывшая Bellcore) завершила исследования по проекту OSCA ТМ , касающиеся новых подходов к созданию информационной архитектуры организации сети (Information Networking Architecture, INA).
Результаты этой работы имеют наименование OSCA/INA [20]. В рамках OSCA предложена концепция использования пакетизирования объектов (object packaging) в виде
блоков построения (building block). Данная архитектура также поддерживает механизм
контрактов (contracts). Контракт можно определить как способ взаимодействия между
менеджером TMN и агентом, который поддерживает MIB на элементе сети. Управляемый объект, который поддерживает локальную MIB, обладает определённым типом,
т.е. атрибутами и операциями. Эти атрибуты и операции предлагаются менеджеру. При
этом автоматически проверяется, соответствует ли реализация менеджера заданному
типу взаимодействия, т.е. контракту с агентом. Таким образом, контракт можно сопоставить с функциями интерфейсов TMN, в частности интерфейса Q, что будет продемонстрировано ниже.
Для реализации распределённой системы разрабатываются соответствующие интерфейсы, а также предлагается трёхуровневая архитектура распределённых вычислений. Интерфейсы, как и в TMN, обеспечивают все характеристики объектов управления, которые видны менеджеру. Предложенная архитектура, как и в случае открытых
систем, обладает свойствами операбельности (operability) и интероперабильности (interoperability). OSCA предлагает расширяемое множество требований к разработке программного обеспечения для обеспечения корректного и ясного поведения многих программных модулей. Также в рамках OSCA сформированы требования к необходимой
функциональности системы для поддержки контрактов, особенно в части технической
поддержки. Основная цель − поддержание единства информации управления на уровне
предприятия связи.
INA предусматривает поддержку слабосвязанных распределённых вычислений
(loosely-coupled distributed computing) и различает контракты на услугу (service
contracts) и контракты на управление (management contracts). Контракт на услугу предлагает необходимую услугу блоков построения, контракт на управления - возможность
наблюдения и конфигурации услуг блоков построения.
Контракты на управление могут быть разделены на несколько видов контрактов
согласно запросам пользователей. В частности, управление лицевым счётом и управление конфигурацией услуги может быть представлено различными контрактами, так как
в биллинге и в конфигурации услуги могут быть заинтересованы различные группы
пользователей. Кроме того, существует различие между пользователем услуг и пользователем управления услугами. Пусть имеется блок построения, который предоставляет
данные о превышении допустимого уровня аварийных сообщений, т.е. в течении определённого интервала времени число сбоев превысило допустимое. Пользователь услуги
заинтересован в своевременном получении соответствующего аварийного сообщения;
пользователя управления услугами заинтересует более подробная информация, в частности, насколько превышен порог, длина промежутка времени, в течении которого произошёл сбой. Для получения подробных данных пользователь управления услугами использует операции блока построения контракта управления.
В рамках OSCA/INA различают следующие блоки построения:
• автоматизации процессов (Process Automation Building Blocks, PABB);
• взаимодействия с пользователем (Human Interaction Building Blocks, HIBB);
• информации предприятия (Enterprise Information Building Blocks, EIBB).
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

174

Блок построения является конечной программной единицей (элементарным модулем), который используется для развёртывания, управления, обеспечения информационной безопасности и интероперабельности распределённых приложений управления. Блок построения может состоять из «пакета объектов» и является намного меньшей единицей программного обеспечения, чем приложение, устанавливаемое на серверной ЭВМ. Конечно, единичный блок построения сам по себе не может решить проблему автоматизации бизнес−процессов. Как правило, необходимо множество блоков
построения, которые «сотрудничают» между собой в рамках логических систем. При
этом блоки построения объединены с помощью шины данных и в результате реализуют
тот или иной процесс ( рис. 7.8).

Контракт
управления

Контракт
услуги

Интерфейс
CAM I

Интерф ейсы

CAMI

СP

Блоки
построения

СP

Блок
построения
провайдера
контрактов

Рис. 7.8 Схема организации блоков построения и контрактов
Блоки построения должны обладать следующими свойствами:
• при развёртывании обеспечивать для системного администратора возможности инсталляции, запуска, останова, обновления, замены, запуска в эксплуатацию, переноса на другие вычислительные платформы;
• при управлении рассматриваться как единичная управляемая сущность для
любой системы или источник информации для приложения управления;
• с точки зрения распределённых вычислений рассматриваться как начальный
блок, который не может быть поделён на меньшие компоненты. При этом
блок построения может быть перенесён с одного компьютера на другой.
Блок построения управляется через интерфейс общего управления приложениями (Common Application Management Interface, CAMI), который позволяет администраторам сети контролировать её работу и быть достаточно хорошо информированными об
эксплуатационных возможностях и производительности сети; управлять независимой
от бизнеса функциональностью блоков построения, тогда как контракты управления
позволяют управлять зависимой от вида бизнес−процесса функциональностью блоков
построения со стороны клиента; определять ошибки и сбои программного обеспечения
и вычислительной техники. С помощью этого интерфейса отслеживается степень заГлава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

175

грузки оборудования и обнаруживаются попытки несанкционированного доступа в систему (вторжения).
В настоящее время существует вероятность того, что CAMI будет основан на
технологии CORBA и взаимодействовать с реализованными с помощью CORBA средствами управления. Появляется возможность реализации шлюза к системе управления
предприятием на основе WEB−технологий. Как альтернатива, данный тип
CORBA−интерфейса будет поддерживать прямое взаимодействие с рабочей станцией
WEB c использованием языка XML (eXtensible Markup Language).
Функциональность блоков построения зависит от того, на каком из трёх уровней
(tier) он находится. В OSCA/INA предлагается три уровня (рис. 7.9):
• уровень информации предприятия (Enterprise Information Tier, EIT),
• уровень автоматизации процессов (Process Automation Tier, PAT),
• уровень взаимодействия с человеком/пользователем (Human Interaction Tier,
HIT).
Уровень EIT определяет хранение и техническую поддержку данных предприятия связи, т.е. данные, которые используются многими бизнес−процессами. Поэтому
блоки построения информации предприятия (EIBB) включают бизнес−правила, имеющие отношение к обеспечению целостности и полноты данных. К примеру, таким правилом может быть правило разрешения конфликтов при множественном обновлении
информации (правило «сохранения работоспособности при последнем обновлении»).
Уровень PAT имеет отношение к бизнес−операциям и управлению. Блоки построения автоматизации процессов (PABB) включают бизнес−правила, которые используются для моделирования бизнес−процессов предприятия связи, и напрямую не затрагивают вопросы целостности и полноты данных, так как этим занимается предыдущий
уровень. Как правило, на этом уровне бизнес−правила реализуются автоматически, без
участия человека.
Уровень HIT имеет отношение к средствам взаимодействия машины (вычислительного средства) и человек, которые создаются на основе дизайна, ориентированного
на пользователя (User Centered Design, UCD), а также на основе управления заданиями,
которые управляет технологией визуализации информации и эффективностью персональной работы пользователя.
Блоки построения взаимодействия с пользователем (HIBB) включают бизнес−правила для организации процессов взаимодействия с пользователем и вызывают
контракты. Теоретически, блок построения на любом уровне может вызвать контракт на
любом другом уровне. Тем не менее, с учётом функциональности блоков построения и
ролей каждого уровня возможны не все комбинации. EIBB существуют для предоставления доступа к данным и поэтому вызывают один другого только для технической
поддержки, синхронизации и сохранения целостности данных. PABB вызывают контракт на любом уровне, включая HIT,так как эти блоки имеют доступ к данным на
уровне EIT и доступ к услугам любых блоков на своём уровне. HIBB вызывают контракты на двух других уровнях, а вот на своём уровне − нет.
Схема на рис. 7.9 показывает, что бизнес−процессы (и реализующие их автоматизацию блоки построения) изолированы от корпоративной информации и общедоступных данных. Таким образом достигается единообразие в доступе к одинаковым данным. Это позволяет избежать проблемы множественных копий данных, что в противном случае потребует дополнительных затрат на синхронизацию и поддержание целостности данных. Бизнес−процессы и данные предприятия отделены от взаимодействия с
пользователем, что также защищает данные от несанкционированного доступа и изменения.
Глава 7. Версия 2.0
А.Ю.Гребешков

Стандарты и технологии управления сетями связи

HIT

176

PAT

f

EIT

Бизнесправила
процессов

Бизнесправила
данных

f
Приватны е
данны е

Управление
заданиями

g

Бизнесправила
работы с
человеком

f

запрос
контракта

Синхронизация
данны х

q

f
Приватны е
данны е

Корпоративны е данны е

Бизнесправила
процессов

Бизнесправила
данных

Общие
данны е
интерф ейсы
TMN

Приватны е
данны е

Рис. 7.9 Трёхуровневая архитектура INA
Шина, которая организует взаимосвязи между блоками построения, называется
окружением распределённой обработки данных (Distributed Processing Environment,
DPE). Для обеспечения совместимости по принципу «поставил− заработало» блоки построения должны иметь чётко определённые роли в рамках логической системы. Для
наилучшего распределения задач, которые призваны решать блоки построения, необходимо применять схемы TOM или стандартизованную МСЭ−Т архитектуру TMN.
Блоки построения предлагают возможности инкапсуляции объектов (object
encapsulation), обеспечивая доступ к себе только через общедоступные интерфейсы, сохраняя при этом недоступными данные о своем внутреннем содержании. Блок построения может функционировать как распределённое приложение, выполняясь на нескольких серверах, но интерфейсы между составляющими блока построения будут недоступны извне для других блоков построения.
Общедоступные интерфейсы блоков построения называются контрактами и
формируются строго в соответствии с определёнными принципами. При этом различают интерфейсы для предоставления контрактов на услуги и интерфейсы для предоставления контрактов на управление.
Универсальный доступ к контрактам блоков построения со стороны окружения
распределённых процессов осуществляется с помощью трейдинговых услуг (trading service), своего рода рекламных, «жёлтых страниц» контрактов. Блоки построения используют трейдинговые услуги для поиска и вызова одного контракта другим. Трейдинг один из элементов, который делает логическую систему слабосвязанной.
Блоки построения также могут быть представлены в виде горизонтальной и
вертикальной архитектуры. В итоге в перспективе возможно будет создан рынок общих
бизнес−объектов (Common Business Objects, CBO). Горизонтальные группы блоков построения состоят из блоков, общих для различных видов управления предприятием,
например управления продажами или управления персоналом. Другие блоки построеГлава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

177

ние, например административное управление соединениями в коммутаторе SDH, используются только в одном секторе телекоммуникаций и могут составлять вертикальную группу, состоящую из частных блоков построения.
В управлении телекоммуникациями общие блоки построения служат прежде всего для реализации требования по предоставлению услуг связи на основе анализа бизнес−процессов с помощью технологической схемы сетевой эксплуатации (TOM).
Предложенная трёхуровневая модель обеспечивает независимость от инженерных технологий организации хранения данных. При этом следует помнить, что при создании модели бизнес−объектов информационная индустрия пользуется единообразными средствами. В целом на уровне HIT в основном используются инженерные технологии представления информации и вывода её на экран (дисплей) с помощью аудиовизуальных средств; функционирование уровня PAT зависит от производительности процессоров ЭВМ; решение задач на уровне EIT зависит от выбранной технологии баз данных. Для соблюдения условий масштабируемости и переносимости приложений могут
использоваться различные языки программирования: на уровне HIT - язык Java, на
уровне EIT - языки SQL или EJB-QL. Итак, для создания современной системы управления телекоммуникациями не меньшее значение, чем схема бизнес−процессов, имеет
применение информационных технологий.

7.5

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

Решения для управления на основе распределённых сред были подготовлены
группой TeleManagement Forum Application Component Team (ACT) как составная часть
схемы интеграции технологий (Technology Integration Map, TIM). Другими словами,
проект OSCA/INA по сути стал частью программы по поддержке разработки программного обеспечения для управления сетями и услугами с целью автоматизации бизнес−процессов сервис−провайдера и оператора связи. Предполагалось, что TIM [28] будет разделена на три основные части.
Часть I. «Положение о направлении развития компонентов приложений» (An
Applications Components Direction Statement) включает критерии разработки для производства тиражируемых или повторно используемых (re-usable) компонент приложений
управления для различных сценариев организации бизнеса в телекоммуникациях.
Часть II. «Положение о направлении развития технологий» (Technology Direction
Statement) включает базовые технологии, на основании которых будет строится система
эксплуатационной поддержки оператора связи (Operating Support System, OSS).
Часть III «Руководство по приобретению» включает соответствующие компоненты из частей 1 и 2, которые могут применяться в качестве готового продукта для
конкретных целей и задач оператора связи и поставщика услуг.
Для того чтобы показать связи между различными элементам TIM в 1999 г. была
разработана структура схемы интеграции технологий (Technology Integration Map
Framework). В рамках TIM наибольшее развитие получила часть I приведённого выше
плана. Структура TIM показывает средства, с помощью которых описываются телекоммуникационные технологии и прикладные задачи для решения задач управления бизнесом. Каждая потребность описывается в сценарии развития предприятия, который подобно срезу проходит через все уровни представленной схемы.
По отношению к TIM схемы Telecom Operation Map (ТОМ) являются вышестоящими (рис. 7.10). Однако между TIM и TOM имеется уровень, который на рис. 7.10 не
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

178

показан и является развитием прикладных задач (application direction). На этом уровне
бизнес-процессы оператора связи моделируются средствами и в терминах прикладных
задач. Важной отличительной особенностью данного уровня является формирование
критериев разработки, которые позволяют создавать вновь используемые приложения.
Тогда указанные компоненты могут использоваться во многих сценариях развития бизнеса.
На совокупность критериев для разработки оказывает влияние множество факторов, часть из которых показана справа от схемы. Например – какая СУБД будет использоваться? Этот вопрос является единичным, но он иллюстрирует решения, которые
необходимо принимать. И такие решение будут существенно влиять на программные
приложения на верхних уровнях.
Далее осуществляется выбор технологий, которые будут поддерживать развитие
прикладных задач. В общем совокупность применяемых технологий обозначается как
Положение о развитии технологий (Technology Direction Statement).
На нижних уровнях указаны действия, которые осуществляются на стадии подготовки и реализации конкретной разработки. В частности, не исключён выбор готовых
решений, которые обеспечивают потребности отдельно взятого оператора связи. Исследовательскими группами TMF разработан проект специального руководства, обозначенного как «интегрированные требования предоставителя услуг к информационным
технологиям» (Service Providers’ Integrated Requirements for Information Technology).
Документ SPIRIT подготовлен совместно TMF и OMG.
Цель SPIRIT - выяснение возможностей предоставителей телекоммуникационных услуг использовать готовые технологии (‘off-the-shelf’ technology, OTS). Значение
этой проблемы стало еще более очевидно после того, как в 1996 г. TMF провёл обсуждение среди поставщиков оборудования и готовых решений. Результаты обсуждения
показали важность использования OTS при внедрении TMN.
В итоге предлагаемая схема предлагает подход, в рамках которого имеется возможность корректно выбирать и применять приложения, технологии для поддержки
приложений, а также готовые компоненты.
На рис. 7.10 показано взаимоотношение программ TMF и процессов разработки
программного обеспечения для управления телекоммуникациями.

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

Уровни
управления
TM N

Бизнес

Услуга

Сеть

179

Элем ент

TO M
Схем а операций/информ ации
Поддерж ивает услуги управления
(предмет руководства
G B921 v. 3.0)
TIM
Прикладное направление
О пределяет, как формирую тся
системные решения (предмет
изучения G B909 v. 3.0)
Исследовательские
програм м ы TM F

Процессы разработки и
создания
Анализ процессов
передачи информ ации
Анализ требований к
управлению
Разработка логики
систем ы
О пределение контрактов

Спецификация технологии
TIM
Технологическое направление
О пределение информационной
технологии
Реш ение о покупке или
собственной разработке
TIM
Руководство по
приобретению
Spirit - расширенный выбор
стандартов

Покупка
блоков
построения

Покупка
средств
разработки

Рис. 7.10 Порядок разработки систем управления телекоммуникациями по версии
TMF
Процесс разработки начинается с анализа бизнес−процессов в рамках схемы
TOM. Анализ требований к программному обеспечению является связующим звеном
между TOM и TIM, и одновременно следующим шагом к разработке и производству
программного обеспечения для автоматизации бизнес−процессов. Анализ требований
даёт в результате необходимые положения о функциональности будущего программного обеспечения. В рамках анализа требований формируется понимание того, как распределённые программные приложения будут разделены на внедряемые программные
модули и какова будет приемлемая степень глубины разбиения на отдельные модули.
Третий шаг − это разработка логической системы (logical system). На этой стадии разработчики программного обеспечения применяют упомянутую выше трехуровневую архитектуру программного обеспечения к требованиям, сформированным по отношению
к распределённому программному обеспечению.
В результате бизнес−процессы разбиваются в принятых определениях на блоки
построения, которые будут взаимодействовать в реальном времени. Выполнению данного условия способствует определение необходимых контрактов.
Следующим шагом в разработке программного обеспечения является определение технологии для внедрения блоков построения. На этом этапе происходит выбор
операционной системы, вычислительной платформы, языка программирования. Эта
стадия соответствует выбору промежуточного программного обеспечения (middleware),
что оказывает непосредственное влияние на интероперабельность будущей системы.
Поэтому в схеме на рис. 7.10 указан этап «Спецификация технологии», что подчёркивает возможность выбора из имеющегося на рынке набора программных продуктов. Сервис−провайдеры или операторы связи могут приобретать готовые блоки построения или
средства для объектно−ориентированного анализа и разработки программного обеспечения.Вследующем разделе показано, как приобретаемые средства могут интегрироГлава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

180

ваться в рамках автоматизированной системы управления оператора [6 ].

7.6

Система OSS оператора связи

Система OSS (Operating Support System) расшифровывается как «система эксплуатационной поддержки» [4], или «система поддержки сетевых операций» [3]. В самом широком смысле под OSS понимаются все автоматизированные/информационные
системы, необходимые для обеспечения основного производства оператора связи –
процесса предоставления услуг и управления сетевыми средствами.
Задачи администрирования и управления множеством услуг связи и инфраструктуры, на которой базируются услуги, являются важнейшими для оператора связи. Для
успешного решения этих задач необходимы специалисты с высоким уровнем технической и психологической подготовки, эффективное применение информационных технологий, оптимальная с точки зрения соотношения затрат/эффективность организация
бизнес−процессов. Все перечисленные факторы в конечном счёте влияют на бизнес
оператора, причём динамически, что обусловлено постоянной конкуренцией на рынке
телекоммуникаций и появлением новых технологий и услуг связи. Соответственно OSS
призвана в комплексе решать задачи автоматизации и информатизации бизнес−процессов оператора связи, связанных с предоставлением, обеспечением и расчётом за услуги связи.
Основными техническими факторами, которые оказывают влияние на состав,
функциональность и архитектуру OSS, являются [25]:
• сетевая инфраструктура, которая представлена различными сетевыми технологиями
(SDH, ATM, DPT) и оборудованием различных производителей. При этом часть сетевых ресурсов может быть арендовано другим оператором;
• типы вычислительных платформ, на базе которых пользователю предлагаются дополнительные услуги связи, например, хостинг, электронная почта, поддержка
IP−телефонии, сервисные телефонные карты. ЭВМ и установленное на них программное обеспечение в процессе оказания услуги взаимодействуют между собой,
создавая тем самым сеть услуг электросвязи (service network);
• повсеместное наличие управления (менеджера) сетевыми элементами − единого или
различного − для оборудования связи и вычислительных платформ. Менеджер элементов сети используется для установки, конфигурации, мониторинга (состояние и
производительность), обслуживания, проверки оборудования систем связи.
Набор функций, необходимый OSS, например, с учётом конкуренции компаний
на рынке услуг местной связи выглядит следующим образом:
Работа с потенциальными пользователями:
• поддержка данных о потенциальных клиентах;
• проверка правильности адресов потенциальных клиентов;
• поддержка доступности услуг связи;
• поддержка специальных цен (маркетинговые компании);
• доступность отдельных компонентов элементов сети (например, наличие
свободной номерной ёмкости или свободных портов).
Предоставление услуги:
• оформление заказа/договора на услуг связи;
• внесение изменений и / или отмена договора;
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

181


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

Графический
интерфейс
пользователя OSS
O SS
другого
оператора

Откры ты е
интерфейсы
API

Биллинг
и CRM

О беспечение
услуги

Управление
сетью
связи

Управление
персоналом

Будущ ие
приложения

О бщ едоступные
ком поненты/
данные

О ткрытый доступ к общ едостпным данным и инф орм ационное
взаим одействие м ежду приложениям и

Уровень адаптации систем управления элементами
Протокол 1

Протокол 2

Протокол 3

Системы
управления
элементами Т Ф ОП, АТ С IP-оборудование AT M, Frame Relay

Протокол 4

SDH, PDH

Протокол 5

О КС№ 7

Рис. 7.11 Структура современной OSS
Принципиальным элементом в рассматриваемой структуре является наличие
уровня адаптации систем управления элементами. Это уровень является своего рода
шлюзом, который преобразует форматы протоколов управления (CMIP, SNMP, HTTP) в
единую форму, данные которой доступны приложениям OSS и могут храниться и обрабатываться в базе данных. Таким образом, имеет место вертикальная интеграция прикладных задач управления и управляемых ресурсов. Эта интеграция соответствует как
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

182

классической концепции TMN, так и направлению работ TMF, и, что вероятно самое
главное, позволяет объединять программные продукты различного назначения.
Воздействие OSS на процесс предоставления услуги связи является скорее эволюционным, чем революционным, что демонстрирует табл. 7.1.
Таблица 7.1
Функциональность OSS
Задачи
оператора
связи

Взаимоотношения с пользователем
Управление профилем услуг
пользователя
Управление
привлечением
клиентов
Проверка доступности телекоммуникационных ресурсов
Управление планом
нумерации
Управление
персоналом
Включение
(активизация)/
выключение услуг связи

Взаимодействие
с пользователм
и
сервиспровайдером

Предоставление
услуг
связи

+++

+

Обеспечение
услуг
связи

Расчёты
за услуги связи
(биллинг)

Уровень
транспортной
сети

Управление
персоналом

++

+
+++

Управление
сетью
связи

+

+
++

+

+

+

+
++

+

+

++
++

+

+

Условные обозначения :
+++ − сильное воздействие OSS
++ − среднее воздействие OSS
+ − слабое воздействие OSS

Помимо вертикальной интеграции, приложениям OSS необходимо обмениваться
информацией между собой и с базой общедоступных сведений. Это позволяет поддерживать информационное единство системы и, в конечном счёте, обеспечивать управляемость OSS. Для обеспечения такого обмена в настоящее время ETSI предлагает использовать концепцию шины сообщений (message bus). Основная задача шины − поддержка обмена сообщениями и данными между компонентами (подсистемами) OSS,
которые подключены к базе. Этот подход позволяет обеспечить интеграцию подсистем
OSS только с шиной, а не с каждым приложением в отдельности. Архитектура данного
решения приведена на рис. 7.12 [29].
Функции шины сообщений состоят в следующем:
• поддержка распределенных приложений;
• гарантированная доставка сообщения адресату. Например, если данное приложение
было временно недоступно, то шина должна распространить сообщение о восстановлении приложения;
• поддержка информационных технологий взаимодействия приложений типа клиент−сервер (запрос − ответ);
• дополнительная функциональность, связанная с обеспечением информационной
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

183

безопасности, поддержкой транзакций.

Продажа
услуг

Обработка
заказов

Планирование и
разработка
услуги

Обработка
проблем

Конфигурация услуги

Ш ина
Планирование и
развитие
сетей

О беспечение
сетей для их
функционирования

Управление
элементом
сети 1

Управление QoS
пользователя

Разрешение
проблем с
услугами

Выставление счетов
и сбор оплат

Управление
качеством
услуги

Начисления и
скидки на
оплату услуг

сообщ ений
Управление
техническим
учётом

Управление
элементом
сети 2

...

Эксплуатация
и восстановление сетей

Управление
данны ми
сети

Управление
элементом
сети n

Рис. 7.12 Информационное взаимодействие компонентов OSS c использованием
шины сообщений (по данным ETSI)
В целом шина сообщений рассматривается как средство промежуточного уровня
и реализуется продуктами соответствующего класса, который называют классом интеграции промышленных приложений (Enterprise Application Integration, EAI). Среди таких стандартов можно привести следующие: CORBA, TIBCO (используется компанией
Hewlett-Packard), Kabira, Corus.
Для того, что бы организовать присоединение приложений к шине сообщений,
необходимо использовать адаптер, или блок адаптации (adaptation unit). В функции такого адаптера входит не только согласование протоколов управления, но и обмен данными между различными интерфейсами API, что было показано на рис. 7.11.
Для шины сообщений принципиально важно согласовать содержание и структуру сообщений, которыми обмениваются подключенные к ней компоненты. Здесь целесообразно применять метки, или теги (tag), известные по описанию форматов ASN.1.
Тег описывает, какой тип данных передаётся, и ставится перед каждым полем данных.
Это механизм позволяет поддерживать целостность системы даже в том случае, если
схема данных изменяется и необходимо обновить те приложения OSS, которые работают с изменёнными данными. При этом прочие приложения OSS не обновляются, так
как работают со «своими» данными, получаемыми из полей сообщений, которые не
были изменены. В настоящее время для такого описания данных, точнее говоря самоописания, широко используется язык XML.
В настоящее время речь идёт не только об обмене данными, но об обмене информационными объектами в рамках общих информационных моделей. Общая информационная модель бизнес-объектов (common business object model) получается путём
конвертации оригинального сообщения в общую информационную модель, после чего
сообщение посылается или публикуется на шине. Конвертация сообщения осуществляется блоком адаптации или специальной функцией конвертации промежуточного обесГлава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

184

печения.
Шина сообщений, общая информационная модель и управление последовательностью выполняемых действия (workflow engine) являются базовыми позициями в рамках новой инициативы TN Forum “OSS сетей связи следующего поколения ” (New
generation OSS, NGOSS).
NGOSS является официально зарегистрированной торговой маркой. Проект
NGOSS, работы по которому ведутся с 2000 г., включает разработку бизнес−подходов к
применению, разработку требований и принципов построения компонентов приложений и инфраструктуры. При этом инфраструктура NGOSS разрабатывается как нейтральная, т.е. с ней смогут взаимодействовать специфические информационные технологии. Работы по проекту NGOSS сопровождаются разработкой спецификаций контрактов (о контрактах см. выше). Схема TOM выступает при этом как схема процессов,
которые будут поддерживаться NGOSS.
Следует сказать несколько слов о стоимостных показателях внедрения OSS.
Стоимость полномасштабного проекта внедрения OSS в том виде, как это представлено
на рис. 7.10, составляет от 5 до 20 миллионов долларов США. Внедрение OSS становится первоочередной задачей всего персонала компании связи − от руководителей высшего звена до эксплуатационного персонала и инженерно−технического состава.
Если учесть, что от 60% до 70% процентов расходов оператора приходится на
сетевые процессы, то OSS позволяет осуществлять эти процессы быстрее и дешевле.
Следовательно, наличие масштабной OSS у оператора связи может иметь решающее
преимущество в конкурентной борьбе.
Отдельно стоит остановиться на вопросе поставщиков OSS. Существует две основные группы − большинство производителей телекоммуникационного оборудования
и некоторые из крупных независимых поставщиков OSS, претендующих на наличие
полной линейки решений OSS. Тем не менее, обе группы поставщиков часто адаптируют свои решения под конкретный бизнес оператора. Для оператора, который работает
на достаточно узком секторе рынка (например, только IP−телефония или только
DSL−доступ) и не намерен расширять свой бизнес в другие рыночные сегменты, может
использоваться «коробочное» решение OSS. Как правило, «коробочное» решение не
требует долгого внедрения и позволяет избегать существенных трудностей, связанных с
системной интеграцией. Разумеется у подобного подхода имеются и существенные недостатки:
• зависимость от единственного поставщика − известно, что не существует поставщика, который был бы хорош всегда;
• гибкость системы − не всегда ясно, что произойдёт, если потребуется иметь дополнительные возможности OSS в случае расширения сферы бизнеса или предоставления новых услуг связи;
• поддержка оборудования многих производителей − не исключено, что при «коробочном» решении возможности поддержки оборудования от различных производителей будут ограничены.
По данным компании JP Morgan Securities Inc, наиболее развитыми в функциональном плане являются три функциональных компонента OSS: взаимодействие с пользователем и биллинг; управление заказами/запросами услуг связи и предоставление услуги; управление сетевыми операциями, т.е. управление сетью. По данным компании
Telcordia совокупный рынок OSS (услуги, аутсорсинг, стоимость программного обеспечения) оценивается примерно в 20…30 миллиардов долларов в год, а компании IDC,
Synergis, JP Morgan прогнозируют, что по состоянию на 2004 г. наибольший доход в
секторе OSS принесут разработки OSS для сетей связи следующего поколения NGOSS,
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

185

разработка биллинга, управление техническими характеристиками сетей связи, создание компонентов для обеспечения функционирования сетей связи, предоставления услуг связи и управления неисправностями. Это говорит о том, что рынок OSS и в особенности компонентов OSS достаточно хорошо развивается.
Российские операторы связи также внедряют OSS. При этом российский вариант
OSS, как правило, строится на основе продуктов как поставщиков телекоммуникационного оборудования (управление элементами сети и, реже, управление сетями связи), так
и продуктов независимых поставщиков OSS. В последнем случае операторам связи поставляются прежде всего биллинговые системы, которые становятся основой для построения современных систем BSS/OSS [9].
Таким образом, российский вариант OSS − это многокомпонентная система, для
которой принципиально важным является наличие открытых интерфейсов для информационного взаимодействия. В настоящее время проводятся работы по выработке корпоративных стандартов информационного взаимодействия компонентов OSS.

7.7

Использование технологии CORBA для задач управления

7.7.1

Архитектура и основные принципы технологий middleware

Существует множество технологий, которые могут применяться к прикладным
задачам управления на основе распределенных систем.
К этим технологиям относятся:
• CORBA (и другие нестандартные системы, ориентированные на брокерский запрос);
• DCE - распределенное компьютерное окружение (среда), разработанная
Open Group;
• DCOM - предлагаемая Microsoft распределенная объектная технология;
• DTP - распределенная обработка транзакций (Distributed Transaction
Processing); которая включает множество продуктов и соответствующих
стандартов, например, X/Open TP, TxRPC, ATMI, CICS.
В настоящее время не существует однозначного мнения в пользу применения
той или иной технологии. Тем не менее, анализ деятельности МСЭ-Т по стандартизации
технологий сетевого управления [21,22], а также документы TMF и публикации
[1,2,23,24,26] позволяют сделать вывод о преимущественном применения технологии
CORBA.
Далее приводятся описания некоторых из перечисленных технологий.
Модель распределенных объектов (Distributed Component Object Model, DCOM)
- это объектное связующее ПО, предложенное корпорацией Microsoft и разработанное
на основе созданных ранее и весьма популярных технологий этой компании - OLE
(Object Linking and Embedding), COM и ActiveX. Технология объектной компоновки
увидела свет в конце 80-х годов и первоначально предназначалась для поддержки широко известной ныне прикладной модели, ориентированной на данные и строящейся на
базе составных документов. В начале 90-х годов вышла редакция OLE 2.0, в которой
была представлена модель объектов-компонентов (Component Object Model, COM). Эта
редакция вскоре стала именоваться просто OLE и в конечном итоге включила в себя
широкий спектр технологий, реализуемых поверх COM.
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

186

В рамках COM был предложен стандарт двоичного интерфейса, позволившего
организовывать службы в виде динамически компонуемых библиотек или приложений
на разных языках программирования. Однако возможности этой модели существенно
ограничивались тем, что она не поддерживала распределенные среды. В DCOM этот
недостаток устранен: клиентам разрешено обращаться к имеющимся службам с удаленных компьютеров через сеть. Технологии OLE сравнительно недавно были переименованы в ActiveX, а термин OLE вновь обрел свой первозданный смысл.
DCOM изначально разрабатывалась с целью интеграции приложений. Идея поддержки распределенной обработки появилась позднее. Характер этой объектной модели
отражает историю ее создания. DCOM поддерживает объектно-ориентированную модель, но такую, которая кардинально отличается от классических образцов.
Объект DCOM предоставляет сервис посредством одного или нескольких отличающихся друг от друга интерфейсов. Он может использовать все свои интерфейсы самостоятельно, а может прибегнуть к методу агрегирования и передать один или несколько интерфейсов в распоряжение других объектов DCOM. Агрегирование позволяет строить приложение из повторно используемых компонентов DCOM.
Другое расхождение с классическими объектно-ориентированными моделями
состоит в том, что DCOM не поддерживает полиморфизм. Сторонники DCOM считают,
что такая поддержка является излишней в модели, главное предназначение которой построение приложений из двоичных компонентов. Заметим, однако, что DCOM не накладывает никаких ограничений на использование в процессе разработки языка, поддерживающего полиморфизм.
Узел-клиент может запросить объект DCOM (используя стандартные методы интерфейсов, реализуемые всеми объектами DCOM) через какой-либо конкретный интерфейс, идентифицируемый уникальным номером. Интерфейс считается постоянным: после того как он опубликован, его не разрешается изменять. Добавление новых функций
в объект DCOM может производиться только путем создания новых интерфейсов.
Хотя между технологиями CORBA и DCOM имеются существенные различия,
обе они поддерживают интеграцию компонентов. Так, DCOM позволяет преодолевать
ограничения, связанные с сетевой средой, языком программирования, унаследованным
ПО и парадигмой. Минусы этой модели связаны с тем, что она не является открытым
стандартом. Хотя Microsoft и заявляет о своем сотрудничестве с такими авторитетными
объединениями производителей, как IETF, в настоящее время DCOM доступна только
на платформах Microsoft. Возможно, ситуация изменится, если другие компании начнут
переносить DCOM на иные платформы, но пока что она не обеспечивает прозрачности
границ, связанных с операционной системой и фирмой-производителем [10].
Представители Microsoft утверждают, что с выходом в свет их нового продукта сервера транзакций (transaction server) DCOM станет полноценной системой масштаба
предприятия, поддерживающей службы именования, событий, защиты, транзакций и
жизненного цикла объектов. Можно ожидать, что в перспективе бесконфликтное сосуществование моделей CORBA и DCOM будет достигнуто. Об этом свидетельствует тот
факт, что OMG детальной рассматривает вопрос взаимодействия COM/CORBA в документе [16].
Аналогично, согласно [1], разработчики Java RMI ( компания Sun Microsystems)
предусматривают, что их технология будет совместима с CORBA.
Распределенная обработка транзакций (Distributed Transaction Processing, DTP)
также рассматривается некоторыми сервис-провайдерами как технология будущего. Эта
технология применяется к приложениям, где набор ресурсов (например, базы данных)
должен быть обновлен за один сеанс работы. Это критически важно для сервиспровайдеров, которые предлагают услуги (на уровне управления услуг), элементы котоГлава 7. Версия 2.0
А.Ю.Гребешков

Стандарты и технологии управления сетями связи

187

рых расположены на многих серверах в различных базах данных. Тем не менее, далее в
настоящей главе именно CORBA рассматривается как ключевая технология для построения распределённых систем сетевого управления.
Технология CORBA (Common Objects Request Broker Architecture - общая архитектура брокера объектных запросов) - это промышленный стандарт на средства взаимодействия в неоднородных вычислительных средах, разработанный Форумом OMG.
“Идейной” основой CORBA является архитектура управления объектами (OMA, Object
Management Architecture) предложенная OMG.
OMA содержит как базовую модель объектов (core object model), так и эталонную модель (reference model). Базовая модель объектов определяет общие способы описания объектов, т.е., иными словами, каким образом «видимые» характеристики управляемых объектов могут быть описаны с помощью стандартных и независимых от конкретных вычислительных систем способов. Эталонная модель предоставляет схемы для
записи данных о компонентах, интерфейсах и протоколах, которые характеризуют
взаимодействие между объектами управления или объектами управления и управляющей системой.
В эталонной модели OMA существуют четыре базовых компонента: брокер объектных запросов (Object Request Broker, ORB), объектные услуги, или услуги объектов
(object services), общие возможности (common facilities) и прикладные объекты (application objects). Таким образом, CORBA − это объектно-ориентированная модель промежуточного уровня, которая определяет множество интерфейсов к ORB, объектным услугам и общим возможностям, которые могут быть использованы для построения распределённых приложений.
Объект в рамках CORBA рассматривается как некоторая сущность (понятие
сущности рассматривалось в главах 2 и 4), которая включает: описание состояния объекта и операций над объектом. Сущность реагирует на запрос услуг. Множество операций над объектом описываются подписями (signature), где указывается название операции, параметры операции и возвращаемое значение. Состояние объекта описывается
атрибутами. Таким образом, модель CORBA позволяет разделить пользователей услуг.
В итоге схема взаимодействия соответствует уже рассмотренной схеме «запрос − ответ»
(рис. 7.13) [16].

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

188

Реализация объекта на сервере

Клиент

DII

ORB
интерфейс

IDL
stub

Стат IDL
шаблон

Динам IDL
шаблон

ORB ядро
Обозначения :

Запрос клиента

Интерфейс, зависимый от ORB
Интерфейс, одинаковый для всех ORB
Есть STUBS и шаблоны для каждого типа объекта
Существует несколько типов адаптеров

Рис. 7.13 Архитектура CORBA
Доступ к объекту устанавливается через определённый интерфейс. Интерфейсы
определяют услуги, которые объекты предоставляют другим объектам системы, и
множество доступных операций (т.е. услуг), которые могут осуществляться на объекте
согласно поступившим запросам. Взаимодействие осуществляется через посылку сообщения (запроса) от данного объекта другим объектам.
Каждый объект CORBA снабжается интерфейсом, определенным на языке описания интерфейса (Interface Definition Language, IDL). Этот язык определяет интерфейсы вместе с их атрибутами и операциями. В начальной форме записи интерфейс на языке IDL не может применяться вычислительными средствами пользователя системы
управления. Для этого код, записанный с помощью языка IDL, должен транслироваться
на языке программирования высокого уровня (например, Си). В итоге реализуется компьютерная программа, которая при запуске будет выполнять функции прикладного программного интерфейса (API).
Центральным элементом CORBA является программа-брокер ORB, или объектная шина [2]. ORB помогает формировать запросы на доступ к объектам, т. е. служит
посредником (брокером) между клиентом и сервером или менеджером и агентом, принимает запрос от пользователя и передает запрос объекту назначения, кроме того, выполняет все необходимые процедуры преобразования информации между средой
управляющей программы (менеджера) и средой управляемого объекта (агента). В состав ORB обычно входят библиотека, которая связывается с каждым процессом
CORBA, и процесс-«демон», участвующий в формировании соединения, но не в других
коммуникационных операциях.
На рис. 7.13 показан запрос клиента к серверу. На сервере находится описание
реализации объекта. Запрос осуществляется посредством ORB. При этом для пользователя, который сделал запрос, неважно, где находится сервер, какие программные средГлава 7. Версия 2.0
А.Ю.Гребешков

Объект
ный
адапте

Стандарты и технологии управления сетями связи

189

ства использованы для описания управляемого объекта, каков тип применяемых форматов данных и т.п. [1,2]. Эти вопросы решает CORBA. Когда клиент (менеджер) вызывает операцию для работы с объектом на сервере (с программой-агентом), интерфейс и
ORB отвечают за механизм, позволяющий найти реализацию требуемого объекта согласно запроса. Объектная шина подготавливает объект к получению запроса, коммутирует итоговые данные по запросу и возвращает результат клиенту.
Запрос клиента имеет сложную структуру и состоит из идентификатора запрашиваемой операции, параметров запроса и объектных ссылок. Объектные ссылки используются для поиска сервера (в TMN – для поиска агента).
В свою очередь, объектный адаптер (object adapter) обеспечивает отображение
ссылок на объект (в данном случае на агент) после установления сеанса связи между
клиентом и сервером (т.е. между менеджером и агентом). Объектный адаптер обеспечивает отображение объектных ссылок в активные реализации объектов (т.е. в агентов,
которые действуют в настоящий момент). При получении запроса от менеджера, объектный адаптер проверяет, активен ли требуемый агент. Если агент неактивен, то объектный адаптер просматривает специальный репозиторий реализаций, или реестр, где
указывается, как активизировать агента. Если агент неактивен, то объектный адаптер
«запускает» его. Объектный адаптер является частью серверной стороны ORB.
Итак, в целом при установлении сессии между агентом и менеджером происходит цепочка следующих операций: поиск элемента сети с агентом, на котором будет
выполняться запрос (на основе объектных ссылок), процессы операционной системы на
элементе идентифицируют требуемого агента; инициируется выполнение требуемой
операции управления.
Благодаря использованию ORB обеспечивается взаимодействие (интероперабельность) между приложениями управления, которые расположены на различных машинах в распределённой среде. Для интерфейса, которым пользуется клиент, не имеет
значение, где находится вызываемый объект и какой язык программирования использует сервер. Подобно всем системам распределённой обработки данных, приложения
управления, реализованные на CORBA состоят из множества объектов, которые взаимодействуют через механизм коммуникации, поддерживаемый ORB. При этом один
объект играет роль клиента (менеджера), а другой – сервера (агента), который отвечает
на запрос клиента. Взаимодействие одной пары клиент – сервер скрыто от другой пары
клиент – сервер. Другими словами, технология CORBA позволяет устранить отмеченный в разделе 7.4 недостаток, когда программное обеспечение менеджера или агента
может выполняться только на одном управляющем устройстве. С использованием
CORBA программное обеспечение агентов и менеджера могут состоять из элементов,
распределенных по нескольким сетевым узлам, что позволяет рационально использовать машинные ресурсы и поддерживать управления сложными территориальноразнесенными сетями связи.
В случае если клиент и сервер имеют полную информацию об интерфейсе IDL,
используется фиктивный модуль (stub). На стороне клиента stub автоматически генерируется из описания интерфейса IDL, отвечающего за порядок выполнения запроса, и
определяет, каким образом клиент вызывает сервер. Здесь осуществляется конвертация
языка программирования, которым пользуется клиент, в тот язык, который будет понятен серверу.
Реализация объекта на сервере будет использовать шаблон (skeleton), который
автоматически генерируется на основе спецификаций IDL, и обеспечивает статический
интерфейс. Статический интерфейс выполняет восстановление порядка данных запроса
в форме, понятной серверу. Описанный статический механизм целесообразен, если интерфейсы в системе изменяются не слишком часто.
Глава 7. Версия 2.0
А.Ю.Гребешков

Стандарты и технологии управления сетями связи

190

ORB поддерживают и другие функциональные возможности. Например, интерфейс динамических запросов (Dynamic Invocation Interface, DII) и интерфейс динамических шаблонов (Dynamic Skeleton Interface, DSI) позволяют производить доступ к объектам, не используя шаблоны, специфические для конкретных типов объектов. Это характерно для случая, когда отсутствует точная информация об используемом интерфейсе. Например, речь может идти о работе шлюзов, или базовой системы управления операциями. Интерфейсы DII и DSI используются совместно с репозиторием интерфейсов
CORBA (Interface Repository, IR), который даёт возможность регистрироваться и получать доступ к спецификациям интерфейса IDL. Используя DII можно построить запрос
пользователя с применением данных, полученных из спецификации интерфейса IR.
При этом ни клиент, ни сервер не знают, какой именно подход, статический или динамический, используется в данный момент.
Достоинство IDL состоит в том, что данный язык разработан только как язык
спецификаций и описаний, аналогично языку SDL или рассмотренному в разделе 4.3
GDMO. В результате интерфейсы, описанные с помощью SDL, могут быть реализованы
на различных языках программирования.

7.7.2

Применение CORBA для реализации интерфейсов сетевого управления

Примеры интерфейсов CORBA для управления сетевыми элементами можно
найти в документе «Multi-Technology Network Management Solution Set. NML-EML Interface Version 2.0. TMF 814. − Version 2.0. − August 2001» (Множество мультитехнологических решений по сетевому управлению. Версия 2 интерфейса NML-EML). Этот документ является результатом работы TMF в части обобщения практического опыта, который накоплен в ходе работ по разработке и внедрению продуктов управления телекоммуникациями. Данный проект носит название Catalyst Project. Его основным результатом являются спецификации применяемых интерфейсов (Interface Implementation
Specification, IIS), которые позволяют реализовать своеобразную «обратную связь» с
работами по автоматизации бизнес−процессов и интеграции технологий.
Разработанные IIS позволяют установить взаимодействие между системой
управления сетью (Network Management System, NMS) и системой управления элементом сети (Element Management System, EMS). При этом роль клиента (источника запросов) выполняет NMS, а роль сервера (ответы на запросы) - EMS. Применение описанного интерфейса позволяет:
• использовать один и тот же интерфейс для управления сетью, использующей несколько технологий (PDH, SDH, ATM, MPLS). В части ATM см., например, [27];
• обнаруживать ресурсы управления, которые находятся под контролем EMS, как при
вводе в эксплуатацию, так и при нормальном режиме работы;
• конфигурировать сетевые терминальные окончания;
• определять использование сетевых ресурсов, а также соединения с присоединёнными сетями;
• запрашивать EMS для установления или разъединения соединения с присоединёнными сетями связи;
• определять наличие физических ресурсов (стойки, стативы, полки, модули) на объектах управления;
• осуществлять контроль технических характеристик загрузки сети связи.
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

191

Вот как, например, описывается в рамках интерфейса IDL структура управляемого элемента – узел системы передачи (мультиплексор или кросс-коннектор):
struct ManagedElement_T {
globaldefs::NamingAttributes_T name; /* Имя управляемого элемента, назначенное EMS
при создании. Этот атрибут используется только для чтения */
string userLabel; /*Имя управляемого объекта, которое назначается оператором, т.е.
NMS. Может быть одинаковым для различных объектов, например один и тот же тип стативов. Атрибут с возможностью
записи/считывания */
string nativeEMSName; /*Имя, под которым объект управления выводится в на экране
рабочей станции для пользователя EMS. Никогда не устанавливается в 0*/
string owner;
/*NMS указывает владельца объекта. Значение атрибута устанавливается с помощью сервиса setOwner через соответствующий интерфейс */
string location;
/*Атрибут устанавливает географическое положение объекта.
Содержание строки любое − координаты, название объекта, номер комнаты, этажа, статива. Может быть пустой строкой. Только
для чтения */
string version;
/*Атрибут устанавливает номер актуальной версии программного
обеспечения управления. Только для чтения */
string productName; /*Атрибут устанавливает тип или название продукта, под которым
объект значится у производителя. Непустая строка. Только для
чтения */
CommunicationState_T communicationState; /*Атрибут устанавливает возможность обмена сообщениями между EMS и объектом управления.
Только для чтения */
boolean emsInSyncState; /*Атрибут устанавливает способность элемента сети и EMS
синхронизировать свои данные. Значения типа false устанавливаются, если имеется расхождение данных и нет возможности сообщить об этом; значения true устанавливаются, когда данные одинаковы и генерируется соответствующее сообщение */
transmissionParameters::LayerRateList_T supportedRates; /*Атрибут в виде списка устанавливает уровень скорости переключений (cross−connect
rate) объекта управления. Только для чтения */
globaldefs::NVSList_T additionalInfo; /*Атрибут в произвольной форме устанавливает
дополнительную информацию, которая передаётся об объекте от EMS к NMS объекта управления. Только для чтения */
};

В рассмотренном выше фрагменте используются следующие условные обозначения:
string - означает строковую переменную;
const - означает, что поле с объявленным в нем ключевым словом является неизменным
в течении всего жизненного цикла программы;
struct – ключевое слово, которое позволяет объединить несколько компонент в переменную с одним именем; в данном случае - ManagedElement_T;
boolean – булева переменная;
/* */ - комментарии;
productName - означает значение атрибута;
:: - указывает на то, что используется сложное полное имя, где “старшее” имя указано
первым, фактически – это иерархия имён объектов. В данном случае:
• globaldefs – имя модуля, который содержит описания общих типов интерфейсов, используемых при взаимодействии MNS – EMS. Другими словами,
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

192

globaldefs - это имя репозитория интерфейсов;
transmissionParameters - имя модуля, который содержит описания, общие для

различных типов передачи, например, используемая технология (SDH), характеристики передачи канального уровня (1.5Mbit/s async/PDH signal,
2Mbit/s PDH signal, OC3_STS3_and_RS_STM1, ATM_VC for ATM Virtual
Channels, Gigabit ethernet, протокол Fibre Channel).
С помощью данного интерфейса оператор системы управления сетью через ORB
обращается к агенту на элементе сети. Агент может сообщить имя элемента сети, его
географическое положение, владельца объекта, т.е. компанию, которая эксплуатирует
элемент сети, версию программного обеспечения управления, типономинал элемента,
возможность сеанса связи с объектом, актуальность данных об элементе в системе
управления EMS, технические характеристики кросс-коннектора. В итоге на экране рабочей станции можно получить картинку, аналогичную рис. 6.9.
Аналогичные описания интерфейсов можно найти в рекомендации МСЭ-Т [21],
в которых, однако, применяется более сложная форма записи с применением некоторых
элементов, унаследованных/транслированных из описания GDMO, которые были выполнены в Рек. МСЭ-Т M.3100, за исключением BasicLayerNetworkDomain (базовое
описание домена сетевого уровня) и BasicSubnetwork (базовое описание подсети или
присоединённой сети), которые были выполнены в рамках Рек. МСЭ-Т G.855.1. В остальных случаях применялась поздняя версия описания классов объектов управления
GDMO. В частности, описанный в Рек. МСЭ-Т интерфейс сети (network interface) основан на спецификациях сети NetworkR1 , выполненных с помощью GDMO. Причём указанная взаимосвязь между описаниями GDMO и спецификациями IDL будет поддерживаться и далее. Здесь же поддерживаются отношения вхождения и наследования. Например, отношения вхождения могут выглядеть следующим образом: ManagedElement
(подчинённый класс объектов) → Network (старший класс объектов) с указанием способов создания и удалений подчиненного класса. Всего в Рек. МСЭ−Т М. 3120 описаны
54 типа интерфейса от управления сетью и программным обеспечением до управления
логическим каналом.
В целом описанию интерфейсов TMN на основе CORBA посвящены следующие
рекомендации:
• Рек. МСЭ-Т Q.816 «Услуги управления TMN, основанные на CORBA» (действует с
01.2001);
• Рек. МСЭ-Т Q.821.1 «Услуги наблюдения за неисправностями TMN, основанные на
CORBA» (для обсуждения с 09.2001);
• Рек. МСЭ-Т Q.822.1 «Услуги управления техническими возможностями TMN, основанные на CORBA» (для обсуждения с 10.2001).
Важный компонент, который обеспечивает переносимость с одной объектно−ориентированной системы на другую, − это объектный адаптер (object аdapter). Как
уже говорилось, каждый объект может реализовываться с помощью различных языков
программирования и операционных систем.
В результате для объектной модели, определённой с помощью CORBA, необходимо адаптироваться к различным программным системам. Если запущена на выполнение та или иная операция, а целевой объект неактивен, его описание необходимо загрузить в оперативную память. С помощью различных объектных адаптеров поддерживаются различные способы реализации объектов. Кроме того, объектный адаптер обеспечивает объектам доступ к услугам ORB.
Каждая операция, которая может быть выполнена на объекте управления, описывается как операция интерфейса. Создание или удаление объекта управления обеспеГлава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

193

чивается объектом Factory. Уведомления о результатах операции описываются другим
интерфейсом, который использует услуги уведомления (рис. 7.14).
Операции на интерфейсе
(например Get, Set, Action)

Управляю щая
система
(программаменедж ер)

Операция уведомления
(Notification)

Объект
управления с
программойагентом

CORBA
(брокеры )

-

Обозначение интерфейса
в нотации ODP

Рис. 7.14 Применение CORBA для сетевого управления
Для каждой операции указывается имя, возвращаемое значение, несколько параметров (хотя их может и не быть) и предложение raises (необязательный компонент).
Атрибуты используются в качестве варианта задания значения, допускающего чтение и
запись. В некоторых случаях запроса на чтение возвращаемое значение может быть
пересчитано, так что атрибуты не должны представлять внутренние переменные (переменные-члены).
В целом для описания объекта управления в CORBA требуется не только язык
IDL. В дополнение к IDL используются объектные услуги (object services) и общие
средства (common services) CORBA. Эти услуги кратко рассматриваются в следующем
разделе. Язык IDL используется для описания операций и типов параметров операций.
Напомним, что в случае «классического» подхода TMN для тех же самых действий требуется две технологии: GDMO и ASN.1. В то же время IDL не предлагает конструкций
для описания поведения объектов управления, поскольку CORBA осуществляет только
передачу операций на сервер и обеспечивает получение ответа (например, данных).
Единственный способ описать поведение объекта управления − это добавить к спецификации IDL соответствующий комментарий.
7.7.3

Услуги CORBA и взаимодействие с CMISE/SNMP

В составе CORBA определены различные службы (услуги, сервисы), расширяющие круг основных возможностей ORB. Некоторые из этих служб функционируют поверх ORB, другие же следует встраивать в ORB, по крайней мере частично. Всего насчитывается до 16 сервисов CORBA.
Наиболее важными для работы сетевого управления являются следующие услуги
(или, как сказано в [11], - службы) CORBA:
• услуга именования (naming service) присваивает объекту символическое имя
и позволяет клиенту получить ссылку на этот объект, организовав поиск по
его имени. Этот сервис является аналогом телефонного справочника для объектов;
• услуга жизненного цикла (life cycle service) управляет созданием, перемещением (копированием) и уничтожением объекта;
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

194

услуга событий (event service) обеспечивает общение пользователей и получателей запросов (в том чмсле асинхронные взаимодействия между анонимными объектами). Клиент отправляет событие (сообщение) по специальному
виртуальному «каналу событий», и это событие передается на все серверы,
зарегистрированные в данном канале. Этот механизм используется для организации многоадресной связи («один со многими»);
• услуга защиты (security service) поддерживает аутентификацию и проверку
полномочий, предоставляя приложениям возможность ограничивать круг
клиентов, которым разрешены те или иные операции. Поддерживает шифрование данных;
• услуга транзакций (transaction service) обеспечивает фиксацию или отмену
всех единичных изменений, производимых приложениями, которые работают
с несколькими серверами и обновляют несколько баз данных.
Для разработки приложений управления на основе технологии CORBA необходимо использовать услуги объектов CORBA (CORBA object services), а также вышеперечисленные услуги.
Как видно из этого перечисления, возможности CORBA могут обеспечивать
функциональность, аналогичную управлению системами по стандартам ВОС: управление объектами, управление состоянием, сообщения о неисправностях, управление сообщениями об аварийных ситуациях, журналирование/регистрация, сообщение о нарушениях безопасности, контроль доступа, управление тестированием и т.п.
Не все из перечисленных возможностей детально разработаны в рамках стандартов CORBA, но все они должны присутствовать в платформе управления на базе
CORBA.
Обеспечение коммуникации между клиентом и сервером по принципам CMISE в
CORBA осуществляется с помощью базовых возможностей взаимодействия при распределённом управлении (basic distributed management interaction facilities). Это принципиально важное свойство CORBA, которое позволяет поддерживать модель управления
«агент - менеджер». С помощью объекта «брокер управления» (management broker)
CORBA обеспечивает интерфейс, аналогичный рассмотренным в главе 5 операциям
доступа CMISE, таким как GET, SET, ACTION, DELETE, CREATE, CANCEL - GET, а
также обеспечивает передачу уведомлений Event-Report. Функционирование объекта
«Брокер управления» [24] поддерживается с помощью услуги выбора объектов (object
selection service). Эта услуга обеспечивает получение ссылок на объекты управления,
список которых выдаёт по запросу брокер управления. Дополнительно здесь используются услуги выбора объектов управления, которые используются для группирования и
фильтрации данных об управляемых объектах.
На основании вышеописанного подхода появляется возможность построить системы управления на основании архитектуры TMN, но с использованием технологий
CORBA. При этом менеджер реализуется на основе принципов CORBA. Это позволяет
использовать большинство возможностей распределённого управления и услуг CORBA
(см. рис. 7.15).

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

Интерфейс
IDL

CORBA
менеджер

CORBA-CMIP шлюз
Брокер
управления
(группировка,
ф ильтрация)

195

Интерфейс CM IP
(Get, Set, Action)
CM IP
агент

Notitfication

Объекты
управления
GDM O

Система управления на CORBA

CMIP агент

Рис. 7.15 Взаимодействие CORBA – CMISE
В итоге приложение управления на основе CORBA включает управляемые объекты и классы менеджеров объектов управления. Средства управления строятся с помощью объектных услуг и возможностей взаимодействия (interaction facilities) CORBA.
Приложение управления запускается «поверх» CORBA. Коммуникативность между
приложениями поддерживается за счёт механизмов CORBA. Взаимодействие с другими
системами операций и элементами сети, которые не поддерживают CORBA, организуется на основе средств управления, объектных услуг и протоколов более низких уровней, например CORBA IIOP. Эти условия надо принимать во внимание при организации
взаимодействия CORBA и «традиционных» систем TMN.
Кроме того, если описание объектов управления выполнено на основе
GDMO/ASN.1, то при использовании CORBA необходима трансляция спецификаций
GDMO/ASN.1 в спецификации IDL. Правила такой трансляции разработаны ETSI и
TMF в виде объединённого междоменного управления (Joint Inter-Domain Management,
JIDM). Такая трансляция, а также организация взаимодействия между системами
CORBA и унаследованными системами «классической»TMN и SNMP предусматривает
наличие шлюзов, которые позволяют реализовать трансляцию.
Схема возможного решения на базе технологии CORBA при условии увязки с
другими технологиями приведена на рис. 7.16, на котором показан случай, когда элемент сети поддерживает агента реализованного с помощью CORBA/IDL, в то время как
приложение управления использует унаследованные технологии. С другой стороны, наличие специальных объектов ORB позволяет организовать шлюз для управления
CORBA−приложением элементов сети с не−CORBA агентами.
Документация
по
службам
CORBA
доступна
на
Web-странице
http://www.omg.org/corba/cfindex.htm.
Сравнение технологий CORBA и CMISE по итогам обсуждения приведена в
табл. 7.2. [30].

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

196

Сетевой элемент
SNM P

CORBA-агент

GDM O/ASN.1

Объект управления

Сетевой
элемент

Объект управления

IDL

Реализация
объекта
управления

Приложение управления

Сетевой
элемент

Агент
TM N
/OSI

SNM P
агент

CM IP
DII

IDL
stubs

ORB
интерфейс

Статичный
IDL
шаблон

Динамический
шаблон

Объектный
адаптер

SNM P

CORBA/
CM IP
шлюз

CORBA/
SNM P
шлюз

IIOP
ORB ядро
IIOP
Для реализации только на CORBA
Для реализации с учётом элементов не-CORBA

Рис. 7.16 Интегральное решение по взаимодействию на базе CORBA
Таблица 7.2
Область
ния

управле-

Протокол
управления
Присвоение
имени
объектам и ссылки на
имена объектов
Услуги ассоциации
Подверженность
ошибкам и сбоям
Услуги
информационной
безопасности
Представление
информации
Операции
управления

Кодирование и декодирование
данных

Глава 7. Версия 2.0

Модель управления ВОС
Телекоммуникации
CMIP

CORBA
Средства вычислительной техники с ориентацией на телекоммуникации
ORB

Дерево имён ВОС

Имена CORBA и объектные идентификаторы OID

ACSE

ORB

При осуществлении операции управления имеются подтверждение выполнения или его отсутствие
Нет встроенного механизма защиты

C помощью услуги Notification service (версия 3.0) с использованием
специального интерфейса
Заново определяемые услуги безопасности

GDMO

IDL

M-GET,
M-SET,
M-CANCEL-GET,
M-CREATE,
M-DELETE

Request
Response
CancelRequest
LocateReply
CloseConnection
MessageError
Упорядочивание и разупорядочивание данных

Кодирование и декодирование с помощью ASN.1

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

197

Можно насчитать не менее 4 сценариев [31] взаимодействия между CORBA и
TMN(SNMP):
1) менеджер CORBA и агент CMIP;
2) менеджер CORBA и агент SNMP;
3) менеджер CMIP и агент CORBA;
4) менеджер SNMP и агент CORBA;
Тем не менее технология CORBA признается некоторыми поставщиками сложной и дорогой. Существуют и иные объектно-ориентированные приложения, подобные
стандартам CORBA, например DCE. Эта технология предпочтительна для тех сервиспровайдеров, кто использует и имеет определенный навык в использовании удаленного
запроса процедуры (Remote Procedure Call, RPC). Преимуществами DCE являются
встроенные системы безопасности и возможности управления системой. Всего DCE
поддерживает около 40 компьютерных платформ.
Тем не менее в последней версии спецификации CORBA приведены достаточно
детальные проработки взаимодействия технологий COM и CORBA, которые позволяют
сделать вывод о том, что фактически CORBA становится ведущим стандартом сетевого
управления. Об этом свидетельствуют данные опроса, которые приводят авторы [3].
Цитируются результаты опроса, которые по запросу группы OMG провела фирма Forester Research. Было опрошено 50 фирм, работающих в телекоммуникациях; из них 44%
используют технологию CORBA и Java, 24% - технологию COM/DCOM, 12% - Java,
CORBA, COM/DCOM, 16% не используют ничего, 4% не занимались этим вопросом
или ничего об этом не слышали. Конечно, по такому опросу трудно делать далеко идущие выводы, однако налицо определённая тенденция, подтверждающая вывод о растущей популярности CORBA.

7.8 Выбор информационной технологии для решения задач
управления телекоммуникациями
Для адекватной поддержки операторов или провайдеров услуг необходима комбинация информационных и телекоммуникационных технологий. Технологии применяются согласно системной роли операторов или сервис−провайдеров в бизнеспроцессах и в сетевом управлении/эксплуатации. Применяемые технологии также разделяются по их системной роли (табл. 7.3) [28].
Таблица 7.3.
№ системной роли
1
2
3
4

Функции системной роли

Возможная технология

Организация доступа пользователя к функциональным подразделениям оператора или к оборудованию связи
Организация взаимодействия
бизнес-процессов
Управление сетевыми ресурсами

Web−браузер/JAVA

Организация доступа к информации о функционировании системы (TM форумом не обсуждался)

CORBA, DCOM, RMI
CMIP/GDMO
SNMP/MIB
SQL, SQL-Net, ODBC, передача
файлов

Системные роли и соответствующий выбор технологии можно прокомментироГлава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

198

вать следующим образом:
Системная роль №1. Основная цель - интегрированный доступ к функциональным
подразделениям оператора связи и/или доступ клиентов к бизнес-процессам и информации сервис-провайдера или оператора связи. В сущности, это поддержка интерфейса
«человек-машина» и системы управления взаимоотношениями с клиентами (Client Relations Management, CRM).
Выбор возможной технологии для системной роли №1. Сервис-провайдеры часто
используют Web браузер и/или Java-приложения для организации доступа. Для некоторых сервис-провайдеров вопросы обеспечения информации и невозможность разделить
данные для облегчения доступа и информационной безопасности являются существенными препятствиями при использовании перечисленных технологий. Многие сервиспровайдеры используют технологии, базирующиеся на WEB, для организации доступа
операторов компании к информации по запросам клиентов. Достоинство данной технологии − в распространенности средств создания приложений.
Системная роль №2. Поддержка взаимодействующих приложений внутри оператора
связи или сервис-провайдера и предоставление сильно связанных приложений управления при взаимодействии между различными операторами связи.
Выбор возможной технологии для системной роли №2 - использование распределенных услуг CORBA. Есть также реальная возможность использования потоковых технологий (workflow) для определения последовательности выполнения приложений. Поскольку использование CORBA становится стандартом как de-facto, так и de-jure, появляется возможность достичь масштабируемости приложений и получить наибольшую
выгоду от распределенных услуг управления.
Системная роль №3. Обеспечивается управление сетевыми ресурсами на уровне
взаимодействия с сетевыми элементами, например, конфигурация, идентификация и
восстановление после повреждений. Cистемная роль характеризуется необходимостью
постоянно отслеживать состояние телекоммуникаций в любое заданное время, реагировать на события, устанавливать приоритеты событий, обрабатывать сообщения о неисправностях и обеспечивать требуемую степень надежности соединений.
Выбор возможной технологии для системной роли №3 - целесообразно применение
архитектуры «менеджер-агент» на основе решений CMIP/GDMO/ASN.1 и SNMP/MIB.
Системная роль №4. Помощь в объединении элементов корпоративной информации и
предоставление реального доступа к сведениям, которые содержатся во многих базах
данных.
Выбор возможной технологии для системной роли №4 - использование SQL как
средства доступа к базам данных или технологии ODP для сетевых баз данных.
Существует множество технологий, которые, напоминая Internet/WWW, могут
обеспечить эффективный по стоимости организации доступ для пользователей.
Среди них можно выделить следующие технологии.
Доступ через Интранет (Intranet). Эта технология обеспечивает различные
способы доступа к данным для самого широкого круга пользователей в административном домене Интернет, который находится внутри сервис-провайдера. Посредством
защиты «firewalls» или других механизмов безопасности контролируемый доступ может быть предоставлен различным группам персонала (например, инженерному персоналу, персоналу отдела маркетинга). Дополнительно эта технология может быть использована для предоставления информации пользователям, например, о состоянии
своих лицевых счетов. Интранет также является хорошим средством для обмена информацией по управлению различного типа, что обеспечивает глобальную точку зрения
на функционирование сервис-провайдера.
Доступ через Web-браузеры.
Глава 7. Версия 2.0
А.Ю.Гребешков

Стандарты и технологии управления сетями связи

199

Объединенная с технологией Интранет, технология браузера WWW представляет собой достаточно простой вариант доступа как к сети Интернет, так и к Интранет.
Эта комбинация эффективна с точки зрения стоимости по следующим причинам:
1. Предлагаемая технология эффективна с точки зрения затрат на нее в случае
большого числа сотрудников или клиентов, которым нужен доступ.
2. Эта технология обеспечивает общую форму интерфейса пользователя для
многих типов приложений.
3. Это наилучший вариант в случае, если клиенты будут устанавливать средства
организации доступа на свои системы.
Мобильный код/JAVA.
Использование мобильного кода обеспечивает новое измерение в развитии распределенных систем. Становится возможным использовать новую технологию «тонкого
клиента» («think» client). Это позволяет использовать сетевой терминал, который обладает только поддержкой Java. В частности, этого достаточно, чтобы поддерживать виртуальную машину JAVA и ее окружение. Данный подход обеспечивает следующие преимущества сервис-провайдерам:
1. Стоимость устройств доступа может быть очень низкой, особенно если для загрузки JAVA используется минимальная конфигурация вычислительных средств.
2. Упрощенное управление конфигурацией программного обеспечения, поскольку при необходимости для загрузки программного обеспечения используется один
источник апплетов (applets). Следовательно, любые обновления программного обеспечения могут производиться централизованно, что облегчает организацию работы пользователей с единой версией программного обеспечения.
Дальнейшее расширение перечисленных возможностей Java позволит сервиспровайдеру предоставлять не только данные по управлению, но и другие приложения,
необходимые клиенту.
Перечисленные в настоящей главе подходы, методы и технологии отнюдь не исчерпывают всего спектра современных решений по управлению сетями и услугами связи. Например, в публикациях [12,14] можно ознакомиться с использованием архитектуры TINA (также использующей ООП и допускающей распределённую обработку данных) для решения задач управления телекоммуникациями.

Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

200

Список источников к Главе 7.
1. Гордеев Э.Н. Использование современных технологий в системах управления сетями связи. // Электросвязь. − 1998. − №7. − С. 8 - 18.
2. Гордеев Э.Н. Новые технологии в системах управления сетями связи // Вестник связи − 2000.− №1. − С. 29 − 32; 2000. − №2 − С. 79 − 83.
3. Ерохин А.В., Корнеев Н.А. TMN : надежда и реальность альтернативных подходов //
Вестник связи − 2000. − №4. – С. 93 – 98.
4. Князев К.Г., Гудрус А.О. Новые ракурсы сетевого управления // Труды MAC. −
2001. − №2(18). – C.20 – 24.
5. Ойхман Е. Г., Попов Э.В. Реинжиниринг бизнеса : реинжиниринг организаций и информационных технологий. − М., Финансы и статистика, 1997 . − 328 с.
6. Построение систем управления сетями связи операторов ВСС РФ. Руководящий документ. – М.: Минсвязи России, 2001.
7. Росляков А.В., Самсонов М.Ю., Шибаева И.В. Центры обслуживания вызовов (Call
center). – М.: Эко-Трендз, 2002. – 272 с.
8. Самсонов М.Ю., Росляков А.В., Денисова Т.Б. Соглашения об уровне обслуживания
в МСС:вопросы и ответы.// Информкурьерсвязь. − 2002. − №8 – С. 32-34.
9. Шибаева И.В. Корпоративная реорганизация – решение есть // Компьютерная телефония. − 2002.− №3. – С. 62 – 64.
10. Цимбал А. Сравнительный анализ технологий CORBA и COM. Режим доступа :
[www.interface.ru/borland/corbacom.htm 3.08.02]
11. Эммерих В. Конструирование распределённых объектов. Методы и средства программирования интероперабельных объектов в архитектруах OMG/CORBA, Microsoft/COM и Java/RMI. Пер. с англ. - М.:Мир, 2002. – 510 с.
12. Adamopoulos D.X., Pavlou G., Papandreou C.A. A UML Based Methodology for the
Creation of TINA Compatible Telecommunications Services. − 1999. Режим доступа :
[www.ee.surrey.ac.uk/Personal/G.Pavlou/Publications/ Conference-papers/Adam-00d.pdf
12.08.02 ]
13. GB910. Telecom Operations Map/ TeleManagmentForum. − March, 2000. − Approved
version
2.1.
Режим
доступа
:
[http://www.tmforum.org/sdata/documents/TMFC1276%20TMFC665%20TMFC31%20G
B910%20v2[1][1].1.pdf 1.09.01]
14. Berndt H., Hamada T., Graubmann P.− TINA: Its Achievements and its Future Directions.
− IEEE Communications. − 2000. Режим доступа [http://www.comsoc.org/pubs/surveys/
16.01.01]
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

201

15. TMF 605. Connection and Service Management Information Model (CaSMIM) Information Agreement./TeleManagementForum − 2001. − Public Evaluation.Version 1.5. Режим
доступа
:
[http://www.tmforum.org/documents/public_evaluation/TMF605v1_5.pdf
10.09.01]
16. CORBA. TheCommonObject Request Broker: Architecture and Specification./ OMG. −
2002. − Version 3.0. Режим доступа [http://www.omg.org/cgi-bin/doc?formal/02-06-33
5.09.02]
17. Corley S., Hickie J. Agent-Oriented Workflow Management for Telecommunications
Business Processes. - Ongoing work of the EURESCOM project P815, Communications
Process Integration using Software Agents. – 1999. Режим доступа :
[http://www.eurescom.de/~pub-deliverables/p800-series/P815/papers/icin2000.doc
15.10.01]
18. GB921. enhanced Telecom Operations Map (eTOM) The Business Process Framework. /
TeleManagmentForum − 2002. − Approved version 3.0. Режим доступа :
[http://www.tmforum.org/sdata/documents/TMFC1279%20TMFC1259%20TMFC1200%
20GB921v3[1][1].0.pdf 5.08.02]
19. Generic Management Model For Corba, Cmip and Snmp. Dissertation der Wirtschaftswissenschaftlichen Fakult. At der Universit. at Zurich zur Erlangung der Wurde eines Doktors
der Informatik vorgelegt von Bela Ban von Kreuzlingen TG. − Dezember, 1997. Режим
доступа : [http://www.cs.cornell.edu/home/bba/papers.html 3.09.02]
20. GB909. Generic requirements for telecimmunications management building blocks. Part 1
of the Technology Integration Map./TeleManagmentForum. − 2001. − Public evaluation
version
3.0
Режим
доступа
:
[http://www.tmforum.org/documents/approved_versions/GB909%20P1v3_0.pdf 7.09.01]
21. ITU-T Recommendation M.3120. CORBA generic network and network element level
information model. − 2001.
22. ITU-T Draft Rec. Study Group 4. TMN Guidelines for Defining CORBA Managed Objects// Telecommunication Standardization Sector Contribution (WP4/4). − Torrance, CA,
USA. − 14 – 18 August, 2000.
23. Park Jong-Tae, Su-Ho and others. Design and Implementation of TMN SMK System Using CORBA ORB// Journal of Network and Systems Management. − Plenum Press. −
June, 1998.− Vol.6. − No. 2.
24. Pavon J. Building telecommunications management applications with CORBA // IEEE
communications surveys. −
Second Quarter 1999. Режим доступа :
[http://www.comsoc.org/pubs/surveys 16.01.01]
25. Pinnes E. Operations and Management for Next Generation Networks./ Presentation in
ASTAP IP-based Networks Management & Internet Charging Seminar Bangkok. − February 22-24, 2001.
Глава 7. Версия 2.0

А.Ю.Гребешков

Стандарты и технологии управления сетями связи

202

26. Potonniée O., Hauw L.H., Ranc D., Bardout Y., Canela Z.. Implementing TMN using
CORBA Object Distribution, Alcatel Telecom RD. – 1997. Режим доступа
[http://olivier.potonniee.online.fr/public/docs/mmns97.pdf 3.09.02]
27. Parasuram Ranganathan, Deepak Sreenivasamurthy A CORBA-based approach for offboard control of ATM switches. − The University of Kansas. − 1998.