close

Вход

Забыли?

вход по аккаунту

?

Grebeshkov Tehnicheskaya ekspluataciya i upravlenie telekommunikacionnymi setyami i sistemami uchebnoe posobie

код для вставкиСкачать
ФЕДЕРАЛЬНОЕ АГЕНТСТВО СВЯЗИ
Федеральное государственное бюджетное
образовательное учреждение высшего образования
«ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ»
Кафедра автоматической электросвязи
А.Ю. Гребешков
Техническая эксплуатация
и управление
телекоммуникационными
сетями и системами
Учебное пособие
Самара
2017
УДК 654.1:621.395
ББК
Г79
Рекомендовано к изданию методическим советом ПГУТИ
протокол № 75 от 12.05.2017 г.
Гребешков А. Ю.
Техническая эксплуатация и управление телекоммуникационными сетями
и системами[текст]/ уч. пособие. – Самара.: ФГБОУ ВО ПГУТИ, 2017. –
200 с.
В учебном пособии рассматриваются вопросы управления современными сетями связи. Рассматривается организация сети управления электросвязью TMN (Тelecommunication Management Network) на основе рекомендаций МСЭ-Т серии М.3000. В конспекте приводится базовая информация по
структуре и особенностям протоколов SNMP. Приведены данные по рекомендациям eTOM, подготовленными TMF и МСЭ–Т. Дан список литературы
для углублённого изучения основ управления сетями связи.
Пособие предназначено для студентов направления подготовки бакалавров по направлению подготовки 11.03.02 «Инфокоммуникационные технологии и системы связи», профиль подготовки «Оптические и проводные
сети и системы связи» очной и заочной формы обучения, в том числе сокращенного срока обучения, магистрантов и аспирантов, интересующихся вопросами управления телекоммуникациями.
Рецензент:
Васин Н.Н. – д.т.н., профессор, заведующий кафедрой «Системы
связи» ФГБОУ ВО ПГУТИ
 ФГБОУ ВО ПГУТИ, 2017
 А.Ю. Гребешков, 2017
СОДЕРЖАНИЕ
СПИСОК ИСПОЛЬЗОВАННЫХ СОКРАЩЕНИЙ ....................... 5
ВВЕДЕНИЕ ......................................................................................... 14
РАЗДЕЛ 1. ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ
ТЕЛЕКОММУНИКАЦИОННЫМИ СЕТЯМИ И СИСТЕМАМИ ..... 15
1.1 ХАРАКТЕРИСТИКА ПРЕДМЕТА ИЗУЧЕНИЯ...................................... 15
1.2 ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ ЕСЭ РОССИЙСКОЙ ФЕДЕРАЦИИ ...... 17
1.3 УПРАВЛЕНИЕ В ГЛОБАЛЬНОЙ ИНФОРМАЦИОННОЙ
ИНФРАСТРУКТУРЕ GII ................................................................................... 21
1.4 КОНТРОЛЬНЫЕ ВОПРОСЫ К РАЗДЕЛУ 1 .......................................... 29
РАЗДЕЛ 2. УПРАВЛЕНИЕ ОТКРЫТЫМИ СИСТЕМАМИ ..... 30
2.1
2.2
2.3
2.4
2.5
ХАРАКТЕРИСТИКА ПРЕДМЕТА ИЗУЧЕНИЯ...................................... 30
ОСНОВНЫЕ ПОНЯТИЯ И ПРИНЦИПЫ УПРАВЛЕНИЯ ВОС ................ 35
ФУНКЦИОНАЛЬНЫЕ ОБЛАСТИ И ФУНКЦИИ УПРАВЛЕНИЯ .............. 39
ХАРАКТЕРИСТИКА ФУНКЦИОНАЛЬНЫХ ОБЛАСТЕЙ ....................... 44
КОНТРОЛЬНЫЕ ВОПРОСЫ К РАЗДЕЛУ 2 .......................................... 47
РАЗДЕЛ 3. УПРАВЛЕНИЕ ТЕЛЕКОММУНИКАЦИОННЫМИ
СЕТЯМИ И СИСТЕМАМИ НА ОСНОВЕ TMN..................................... 48
3.1 СОСТАВ И НАЗНАЧЕНИЕ ОСНОВНЫХ ЭЛЕМЕНТОВ TMN ................ 48
3.2 ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ И АРХИТЕКТУРА TMN .......... 51
3.1 ИНТЕРФЕЙСЫ TMN ....................................................................... 65
3.3.1 Общие сведения об интерфейсах TMN ................................ 65
3.3.2 Описание интерфейса Q ................................................... 67
3.3.3 Описание интерфейса X.................................................... 72
3.4 ОПИСАНИЕ ИНТЕРФЕЙСОВ F И G .................................................. 77
3.5 КОНТРОЛЬНЫЕ ВОПРОСЫ К РАЗДЕЛУ 3. ......................................... 81
РАЗДЕЛ 4. ИНФОРМАЦИОННАЯ МОДЕЛЬ УПРАВЛЕНИЯ
ТЕЛЕКОММУНИКАИЦОННОЙ СЕТЬЮ ............................................. 82
4.1 ОСНОВНЫЕ КОМПОНЕНТЫ ИНФОРМАЦИОННОЙ МОДЕЛИ
УПРАВЛЕНИЯ ................................................................................................. 82
4.2 ИНФОРМАЦИОННАЯ МОДЕЛЬ SID TELEMANAGEMENT FORUM ..... 95
4.3 КОНТРОЛЬНЫЕ ВОПРОСЫ К РАЗДЕЛУ 4 ........................................ 106
РАЗДЕЛ 5. КАРТА ПРОЦЕССОВ ТЕХНИЧЕСКОЙ
ЭКСПЛУАТАЦИИ ETOM ОПЕРАТОРОВ СВЯЗИ ............................. 107
5.1 БИЗНЕС–ПРОЦЕССЫ И ФОРМИРОВАНИЕ КАРТЫ ETOM ............... 107
5.2 НАЗНАЧЕНИЕ УРОВНЕЙ ETOM В ОБЛАСТИ ТЕХНИЧЕСКОЙ
ЭКСПЛУАТАЦИИ .......................................................................................... 116
5.3 КОНТРОЛЬНЫЕ ВОПРОСЫ К РАЗДЕЛУ 5 ........................................ 121
РАЗДЕЛ 6. СИСТЕМЫ УПРАВЛЕНИЯ
ТЕЛЕКОММУНИКАЦИЯМИ OSS/BSS ................................................. 122
6.1
6.2
6.3
6.3
ПОНЯТИЕ О СИСТЕМЕ OSS ОПЕРАТОРА СВЯЗИ ............................ 122
ВОЗДЕЙСТВИЕ OSS НА УСЛУГИ СВЯЗИ........................................ 126
РАЗВИТИЕ СИСТЕМ СЕТЕВОГО УПРАВЛЕНИЯ ............................... 130
КОНТРОЛЬНЫЕ ВОПРОСЫ К РАЗДЕЛУ 6 ........................................ 136
РАЗДЕЛ 7. ТЕХНИЧЕСКАЯ ЭКСПЛУАТАЦИЯ СЕТЕЙ И
СИСТЕМ СВЯЗИ ....................................................................................... 137
7.1
7.2
7.3
7.4
ТЕХНИЧЕСКАЯ ЭКСПЛУАТАЦИИ И ИЗМЕРЕНИЯ НА СЕТЯХ СВЯЗИ . 137
ИЗМЕРЕНИЯ НА СЕТЯХ СВЯЗИ В ПРОЦЕССЕ ЭКСПЛУАТАЦИИ ....... 141
ОСОБЕННОСТИ ЭКСПЛУАТАЦИИ ЦИФРОВЫХ СИСТЕМ СВЯЗИ ....... 145
КОНТРОЛЬНЫЕ ВОПРОСЫ К РАЗДЕЛУ 7 ........................................ 152
РАЗДЕЛ 8. ПРОТОКОЛ SNMP ДЛЯ УПРАВЛЕНИЯ СЕТЯМИ
СВЯЗИ.......................................................................................................... 153
8.1
8.2
8.3
8.4
8.5
ОБЩИЕ СВЕДЕНИЯ О ПРОТОКОЛЕ SNMP..................................... 153
ИНФОРМАЦИОННАЯ МОДЕЛЬ УПРАВЛЕНИЯ MIB SNMP ............. 157
ЭЛЕМЕНТЫ ПРОТОКОЛА SNMP .................................................. 167
ОСОБЕННОСТИ ПРОТОКОЛА SNMP ВЕРСИИ 3 ............................ 174
КОНТРОЛЬНЫЕ ВОПРОСЫ К РАЗДЕЛУ 8 ........................................ 179
РАЗДЕЛ 9. УПРАВЛЕНИЕ СЕТЯМИ СВЯЗИ СЛЕДУЮЩЕГО
ПОКОЛЕНИЯ ............................................................................................. 180
9.1
9.2
9.3
9.4
СЕТИ NGN И ОСОБЕННОСТИ УПРАВЛЕНИЯ ИМИ ........................ 180
УПРАВЛЕНИЕ КАЧЕСТВОМ УСЛУГ В NGN ................................... 188
ТЕХОБСЛУЖИВАНИЕ И ТЕХЭКСПЛУАТАЦИЯ СЕТЕЙ NGN ............ 193
КОНТРОЛЬНЫЕ ВОПРОСЫ К РАЗДЕЛУ 9 ........................................ 199
УЧЕБНАЯ ЛИТЕРАТУРА ............................................................. 199
4
СПИСОК ИСПОЛЬЗОВАННЫХ СОКРАЩЕНИЙ
A
– Agent – Агент
AIS
– Alarm Identification Signal – Сигнал индикации аварийного
состояния
– Adaptation device – Устройства адаптации
AD
ADC
ADSL
AF
ANSI
AP
AP
API
ACCD
ASN.1
ATM
BER
 Accounting data collection and conversion  Сбор и трансформация данных для расчёта стоимости услуг связи
– Asymmetrical Digital Subscriber Line – асимметричная цифровая абонентская линия
– Application Function – Функции приложения
– American National Standard Institute – Американский национальный институт стандартов (США)
– Application Process – Прикладной процесс
– Application Protocol – Прикладной протокол в GII
– Application Programming Interface – Прикладной программный интерфейс
– Available Connections Change Dissemination – Распространение по сети изменений данных о доступных соединениях
– Abstract Syntax Notation no 1 – Абстрактная запись синтаксиса № 1
– Asynchronous Transfer Mode – Асинхронный режим переноса
(передачи)
– Basic Encoding Rules – Базовые правила кодирования (данных)
BMF
 Basic management functions  Базовая функция управления
BML
– Business Management Layer – Уровень управления бизнесом
BML
BPI
– Business Management System – Система управления бизнесом
– Basic Programme Interface – Базовый программный интерфейс
СERT
 Computer Emergency Response Team – Группа реагирования
на угрозы безопасности компьютерных систем
CDMA
 Code division multiplexing access –Технология мультидоступа с кодовым разделением каналов
5
CF
CLNS
– Control Function – Функция контроля в GII
 Сonnectionless-Mode Services  Услуги протокола без установления соединения
CMIP
CMIS
COM
CONS
– Common Management Information Protocol – Общий протокол
информации управления
– Common Management Information Service – Услуга общей
информации управления (услуга информационного протокола
общего управления)
– Component Object Model –Компонентная модель объектов
 Сonnection-Mode Services  Услуги протокола с установле-
CCS №7
нием соединения
– Common Channel Signaling no 7 – Общеканальная система
сигнализации №7
CUA
 Common User Access  Общий доступ пользователя
DCF
DCC
– Data Communication Function – Функция передачи данных
– Data Communications Channel – Служебный канал передачи
DCE
данных
– Distributed Computing Environment – Распределённая компьютерная обработка
– Data Communication Network – Сеть передачи данных
DCN
DLC
 Deliverable Link Connection  Предоставляемое соединение
DPT
звена
- Dynamic Transport Data – протокол динамической передач
DSL
DWDM
ECC
пакетов
– Digital Subscriber Loop – Цифровая абонентская линия
–
Dense
Wavelength
Division
Multiplexing
–
Мультиплексирование с разделением по длине волны
– Embedded Communication Channel – Встроенный канал пере-
EEI
EML
EMS
дачи данных
– Environment External Interface – Интерфейс внешней среды
– Element Management Layer – Уровень управления элементом
– Element Management System – Система управления элементом
ETSI
– European Telecommunication Standard Institute – Европейский
6
институт стандартов в области связи (телекоммуникаций)
ES
 End System  Оконечная открытая система
FTAM
 File Transfer Access Method  Управление доступом передачи
файлов
FTP
 File Transfer Path  Протокол передачи файлов
GDMO
– Guidelines for Definition of Managed Objects – Общее опреде-
GII
GPRS
ление объектов управления
- Global Information Infrastructure – Глобальная информационная инфраструктура
- General Packet Radio Service – Общая радиослужба передачи
данных
HCIF
HCIF
– Human-Computer Interfacing – Интерфейс «человек-машина»
– Human-Computer Interfacing Function – Функция интерфейса
«человек-машина»
HDLC
 High-level data link control protocol  Протокол высокого
HDSL
уровня для управления каналом передачи данных
- High Bit Rate Digital Subscriber Line – Цифровая абонентская
линия с высокой скоростью передачи данных
HMI
 Human-machine interface – Интерфейс «человек – машина»
HTTP
 Hypertext Transfer Protocol – Протокол передачи гипертекстовой информации
HTML
 HyperText Markup Language  Язык гипертекстовой разметки
IEEE
(в сети Интернет)
– Institute of Electrical and Electronics Engineers – Институт
IETF
инженеров по электротехнике и электронике
– Internet Engineering Task Force – Рабочая группа по инженерным проблемам Интернета
IMIB
- Internet Management Information Base – Интернет-база информации управления
INAP
 Intelligent Network Application Part – Прикладная подсистема
IP
IS
пользователя интеллектуальной сети в ОКС №7
Internet Protocol –Протокол межсетевого взаимодействия
Intermediate system – Промежуточная открытая система
7
IS-IS
Intermediate system to intermediate system – Протокол взаимодействия промежуточных систем
ISDN
– Integrated Service Digital Network– Цифровая сеть с интеграцией служб, ЦСИС.
– International Standard Organization – Международная организация по стандартизации
– International Telecommunication Unit – Международный союз
ISO
ITU
ITU-T
электросвязи
– International Telecommunication Unit – Standardization Sector –
Международный союз электросвязи – сектор стандартизации
LAN
 Local Area Network  Локальная вычислительная сеть
LAPB(D)
 Link Access Procedure B (D) – channel  Процедура доступа к
линии B(D)канала
LC
 Link Connection  Соединение тракта
LCC
 Logical Link Control  Протокол управления логической ли-
LCS
LLA
нией
– Leased Circuit Services – Услуга аренды линии
– Logical Layer Architecture – Логическая многоуровневая архитектура
LT
M
MAF
ManF
MAS
MCF
MD
MESA
MF
MF
– Line Terminal – Линейное окончание в ISDN
– Manager – Менеджер, программная логика
Manager Application Function – Функция приложения управления
Management Function – Функция управления в GII
Management Association Services – Услуги управления связями
(между приложениями)
– Management Communication Function – Функция передачи
сообщений
– Management Device – Устройство медиации, медиатор
– Mobile e-Services Architecture – Архитектура мобильных
электронных услуг
– Mediation Function – Функция медиации
– Middleware Function – Функции промежуточного слоя (промежуточного ПО) в GII
8
MFS
 Management function sets  Множество функций управления
MIB
MIS
– Management Information Base – База информации управления
– Management Information Service – Услуга информации по
MNS
MO
управлению
– Management Notification Service – Услуга управления уведомлениями
– Management Object – Управляемые объекты, объекты управления
NE
– Middleware Protocol – Протокол промежуточного уровня в
GII
– Multi-Protocol Label Switch – Многопротокольная коммутация на основе меток
– Network Element –Элемент сети, сетевой элемент
NEF
NEL
NIC
NF
NIST
– Network Element Function – Функция элемента сети
– Network element layer – Уровень элемента сети
– Network Interface Card – Сетевая интерфейсная карта
- Network Function – Функция сети
– National Institute of Standards and Technology – Националь-
MP
MPLS
NMF
NML
NMS
NPDU
NT
ODP
OMG
OS
OSS
ный институт США по стандартам и технологиям
– Network Management Forum – Форум cетевого управления,
сейчас преобразован в TMF.
– Network Management Layer – Уровень управления сетью
– Network Management System – Система управления сетью
– Network Protocol Data Unit – Сетевой блок данных протокола
– Network Terminal – Сетевое окончание в ISDN
– Open distributed processing – Открытая распределённая обработка [данных]
– Object Management Group – Группа по управлению объектами, неправительственная организация
– Operation System – Управляющая система (операционная система)
– Operation Support System – Система эксплуатационной поддержки и управления сетями связи
9
OSF
OSI
– Operation System Function – Функция управляющей системы
– Open System Interaction – Взаимосвязь открытых систем
OSIE
– Open System Interaction Environment – Среда взаимосвязи открытых систем
– Protocol Data Unit –Блок данных протокола
– Remote Procedure Call – Удалённый вызов процедуры
– Processing and Storage Function – Функция обработки и хра-
PDU
RPC
P&SF
PСI
Q
QA
QAF
QoS
RAD
RDSL
RFC
RMON
ROSE
RPC
SAP
SCF
SDH
нения информации.
– Protocol control information – Управляющая информация протокола
– Q-interface – Q-интерфейс
– Q-adapter – Q-адаптер
– Q-adapter Function – Функция Q-адаптера
– Quality of Service – Качество обслуживания
– [user] Requirements, Analysis and Design – требования пользователя, анализ и разработка
– Rate Adaptive Digital Subscriber Line – Цифровая абонентская
линия с адаптивной скоростью передачи
– Request For Comments – обозначение документа IETF
– Remote Monitoring – Дистанционный мониторинг
– Remote Operations Service Element – Элемент услуги удалённого выполнения операций
– Remote Procedure Call – Удалённый (дистанционный) запрос
процедуры.
– Service Access Points – Точка доступа к услуге
– Service Control Function – Функция контроля услуг
– Synchronous Digital Hierarchy – Синхронная цифровая иерар-
SDU
SDSL
хия
– Specification and Description Language – Язык спецификаций
и описаний
– Service data unit – Блок данных услуги
– Symmetrical Digital Subscriber Line – Симметричная цифро-
SLA
вая абонентская линия
– Service Level Agreement – Соглашение об уровне обслужива-
SDL
10
SMAE
ния
Service Management Application Element – Прикладной объект
SMASE
управления системой
Service Management Application Service Element – Элемент
прикладной услуги управления системой
SMC
Service Management CenterЦентр управления услугами
SMI
Structure of Management Information – Структура информации
управления (управляющей информации)
SMF
SML
SMK
Systems Management Function – Функция управления системой
Service Management Layer – Уровень управления услугами
– Shared Management Knowledge – Управление знаниями об
объекте управления
– Service management layer – Уровень управления услугами
SML
SMS
SNC
– Service management system – Уровень управления услугами
 SubNetwork Connections  Соединение подсети
SNMP
– Simple Network Management Protocol – Простой протокол
сетевого управления
STM
Synсhronous Transport Module  Синхронный транспортный
модуль.
SUNI
 Service user network interface Сетевой интерфейс обслужи-
SQL
вания пользователя
– Server-Client Language – Язык запросов Сервер-клиент (архитектура «клиент-сервер»)
TF
TF
– Transformation function – Функция преобразования
– Transport Function – Транспортная функция в GII
TCP
– Transmission Control Protocol – Протокол контроля передачи
(входит в стек протоколов TCP/IP)
TMF
– TeleManagement Forum – Форум по управлению телекоммуникациями, неправительственная организация
TMN
– Telecommunications Management Network – Сеть управления
электросвязью
TRP
–Telecommunications Reference Point – Опорная точка сети
электросвязи
UDP
– User Datagram Protocol –Протокол передачи дейтаграмм
11
UML
UMTS
UNI
UCD
VС
VС-n
VDSL
VoIP
VPN
X.25
пользователя
– Unified Modelling Language – Язык унифицированного моделирования
–
Universal
Mobile
Telecommunications
System
–
Универсальная система мобильной связи
– User-Network Interface – Интерфейс «пользователь – сеть».
– User Centered Design – Дизайн интерфейса, ориентированный на пользователя
– Virtual Container – Виртуальный контейнер
– Virtual Container of level n – Виртуальный контейнер уровня
n (n=12, 2,3,4)
– Very High Bit Rate Digital Subscriber Line – Цифровая абонентская линия с очень высокой скоростью передачи битов
– Voice over IP – передача голоса по протоколу IP
– Virtual Privet Network – виртуальная частная (выделенная)
сеть
– Сеть передачи данных по протоколу X.25
WS
WSF
– X-adapter – Адаптер интерфейса X
- Wide Area Network – глобальная вычислительная сеть (или
сеть связи )
– Working Station – Рабочая станция
– Working Station Function – Функция рабочей станция
АСУ
 Автоматизированная система управления (сетью связи)
АСУ ТП
 Автоматизированная система техничнского учета и паспор-
X-adapter
WAN
тизации
АТСЭ
– Автоматическая телефонная станция электронная
БД
ИСО
– База данных
– Международная организация по стандартизации
ГОСТ
ГОСТ Р
– Государственный стандарт
ЛВС
 Локальная вычислительная сеть (LAN)
ЛОНИИС
 ФГУП «Ленинградский отраслевой научно -
МСЭ
исследовательский институт связи»
– Международный союз электросвязи
 Государственный стандарт России
12
МСЭ-Т
МЭК
– Сектор стандартизации электросвязи МСЭ
– Международная электротехническая комиссия, IEC
НСД
ПО
РМУС
РД
СУБД
– Несанкционированный доступ (к данным, к оборудованию)
– Программное обеспечение
– Рабочее место управления сетью (связи)
– Руководящий документ
– Система управления базами данных
СУЭС
СУС
ТУ
ТЦУ
ТФОП
– Сеть управления электросвязью
– Система управления сетями (связи)
– Технический учет
– Территориальный центр управления
УПАТС
– Учрежденческо-производственная АТС
УС
УЦУ
ЦСИО
ЦСИС
ЦНИИС
– Устройства сопряжения
– Узловой центр управления
– Цифровая сеть с интегральным обслуживанием
– Цифровая сеть с интеграцией служб
– Центральный научно-исследовательский институт связи, г.
ЦТЭ
ЦУ
ЦУ-З
ЦУ-М
Москва
– Центр технической эксплуатации
– Центр управления (сетями электросвязи)
– Центр управления оператора зонового уровня
– Центр управления оператора местного уровня
ЦУ-Ф
ЦУ-ЭС
ЧС
ЭВМ
– Центр управления оператора федерального уровня
– Центр управления элементами сети
– Чрезвычайная ситуация
– Электронно-вычислительная машина
Телефонная сеть связи общего пользования (также ТфСОП).
13
ВВЕДЕНИЕ
Оказание услуг электросвязи на возмездной основе неразрывно связано
с вопросами комплексного управления сетями связи. Цель управления –
обеспечение требуемого уровня качества услуг связи и заданных параметров
функционирования сетей связи. Задача управления сетью состоит в том, чтобы оператор связи имел возможность дистанционного мониторинга, контроля и воздействия на оборудование связи с помощью автоматизированных
средств. Наиболее эффективно задачу управления сетями электросвязи можно решить, применяя концепцию построения сети управления электросвязью
(telecommunication management network, TMN).
Применение TMN актуально в связи с продолжающейся интеграцией
сетей с коммутацией каналов и сетей с коммутацией пакетов, повсеместной
поддержкой средств мультимедиа на коммутационных узлах. Возросший
объем сетевой нагрузки, сложные архитектуры и топологии сетей требуют
использования программно-аппаратных комплексов, программного обеспечения, позволяющих контролировать работу любых систем связи в реальном
времени. Соответственно, на основе принципов TMN разрабатываются и
внедряются системы и платформы сетевого управления, которые позволяют
управлять сетями связи по единым принципам, вне зависимости от технологических особенностей оборудования и систем связи различных типов.
Предметом данного учебного пособия является рассмотрение вопросов,
связанных с современными подходами к управлению телекоммуникациями.
Рассматриваются основные принципы управления TMN, используемые информационные технологии, протоколы управления. Приводятся примеры
практической реализации систем и платформ управления сетями связи.
14
РАЗДЕЛ 1. ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ
ТЕЛЕКОММУНИКАЦИОННЫМИ СЕТЯМИ И
СИСТЕМАМИ
1.1 Характеристика предмета изучения
За последние годы структура телекоммуникационных сетей стала более
сложной и многоплановой. Наряду с традиционными аналогово-цифровыми
телефонными сетями связи бурно развиваются новые цифровые сети связи с
коммутацией пакетов на основе технологий Frame Relay, АТМ, MPLS. Повсеместное применение протокола IP и развитие сети Интернет сделало возможным появление на рынке IP-телефонии и других телематических служб.
Развитие транспортных сетей со скоростью передачи данных от 2 Мбит/сек
до 256 Гбит/сек повлекло за собой развитие сетей высокоскоростного абонентского доступа как на базе традиционной технологии ЦСИС, так и с использованием технологий семейства DSL (ADSL, XDSL, SDSL, HDSL). В
подвижной радиосвязи начинается переход к сетям связи 3-го поколения на
базе стандартов UMTS и CDMA.
В итоге, сети связи становятся гетерогенными т.е. состоящими из многих типов оборудования связи и систем передачи информации. Неизбежно
возникает необходимость автоматизации контроля, мониторинга и управления разнородным оборудованием и системами связи на основе единых принципов. Это требуется для поддержания требуемого уровня качества связи
для различных категорий пользователей. Для выполнения указанной задачи
оператор связи должен иметь центр управления сетями и/или услугами связи,
который позволяет решать следующие производственные задачи :
 быстро внедрять новые услуги связи для приобретения новых клиентов и получения дополнительных источников доходов;
 поддерживать нормативное качество обслуживания клиентов,
включая минимизацию времени восстановления оборудования после сбоев или отказов;
 обеспечивать круглосуточную техническую поддержку пользователей;
 снижать затраты на эксплуатацию сети при разумном соотношении
«стоимость/производительность/надёжность».
Организация интегрированного управления современными сетями связи требует применения соответствующих программно-аппаратных платформ,
которые функционируют в рамках автоматизированной системы управления связью (АСУ).
Для решения задачи интегрированного управления Международный
союз электросвязи предлагает использовать концепцию сети управления
электросвязью TMN. TMN есть «… специальная сеть, обеспечивающая
управление сетями электросвязи и их услугами путём организации взаимо15
связи с компонентами различных сетей электросвязи на основе единых интерфейсов и протоколов, стандартизованных МСЭ-Т» [18,19]. Применение
TMN предполагает комплексный подход к управлению сетями связи, начиная с управления бизнесом оператора и услугами связи (верхний уровень
управления) и заканчивая управлением отдельным устройством или элементом сети (нижний уровень управления).
Техническую основу TMN составляет специальная сеть управления. В
совокупности с организационнотехническими решениями и современными
информационными технологиями на базе TMN появляется возможность контролировать процесс оказания услуг связи, воздействовать на рабочие характеристики оборудования и систем связи. Для этого используются функциональные элементы TMN со стандартизованными интерфейсами взаимодействия и подключения. Под функциональным элементом здесь понимается
компонент TMN, который выполняет определённую функцию, например
функцию мониторинга характеристик коммутационного оборудования,
функцию сети передачи данных, функцию отображения информации управления для администрации связи. В рамках TMN предусматривается техническая возможность целенаправленного воздействия на характеристики оборудования, например установка порога перегрузок, изменение характеристик
абонента, блокировка направления связи, перенаправление нагрузки и т.п.
Согласно рекомендациям МСЭ-Т серии M.3xxx (см. Приложение 1),
TMN имеет интерфейсы с телекоммуникационной сетью в обусловленных
точках стыка. Эти интерфейсы используются для обмена информацией
управления, предоставления услуг управления, а также для приёма-передачи
управляющих команд между системой управления и оборудованием связи.
В сферу управления попадают практически все существующие в настоящее время виды сетей и систем связи, соответствующие типы телекоммуникационного оборудования:
 сети связи общего пользования и выделенные сети;
 оборудование систем передачи (мультиплексоры, кросс-коннекторы,
каналообразующее оборудование и т.д.);
 линии связи (медные и волоконно-оптические кабельные системы,
радиорелейное оборудование, спутниковое каналообразующее оборудование);
 программное обеспечение оборудования связи;
 аппаратное обеспечение вычислительных комплексов;
 цифровые и аналоговые коммутаторы, сети связи, включая информационно-вычислительные сети (локальные и глобальные);
 сама сеть TMN (т.е. управление сетью TMN);
 системы сигнализации;
 телематические службы и телесервисы;
 программное обеспечение, необходимое для предоставления телекоммуникационных услуг (например, услуги интеллектуальных сетей);
16
 прикладное программное обеспечение (ПО) вычислительных систем;
 системы электропитания, инженерного обеспечения (системы безопасности, пожаротушения, системы кондиционирования воздуха и
т.д.).
Основы организации управления ВСС РФ изложены в следующем разделе.
1.2 Организация управления ЕСЭ Российской Федерации
В целом под системой управления сетью электросвязи понимается
«система, выполняющая функции по управлению сетью на основе комплекса
информационных технологий по планированию, техническому обслуживанию, эксплуатации, оперативному и административному управлению сетями
и предоставляемыми услугами».
Система управления сетью связи оператора связи обеспечивает решение следующих основных задач в повседневных условиях:
 мониторинг функционирования сети электросвязи в целях обеспечения контроля состояния и прогнозирования возникновения аварийных ситуаций на сети связи, в том числе связанных с разрушающими информационными воздействиями, а также координацию
работ по обеспечению целостности, устойчивости функционирования и безопасности своих сетей связи;
 координацию деятельности обслуживающего персонала по выявлению угроз информационной безопасности сети и средств электросвязи, в том числе по обнаружению и ликвидации последствий
компьютерных атак на сеть связи;
 планирование использования сети связи в чрезвычайных ситуациях
и в условиях чрезвычайного положения;
 предоставление оперативной информации по запросу федерального
органа исполнительной власти в области связи для реализации его
полномочий, в том числе информации о техническом состоянии,
перспективах развития сети связи и средств связи, об условиях оказания услуг связи, услуг присоединения и услуг по пропуску трафика, о применяемых тарифах и расчётных таксах;
 организацию и проведение совместных тренировок обслуживающего персонала узлов связи сети связи оператора с персоналом узлов
связи сетей связи специального назначения по проверке готовности
предоставления указанными сетями дополнительных ресурсов по
требованию спецпользователей (при наличии соответствующих договоров).
Система управления сетью связи оператора связи обеспечивает решение следующих основных задач в чрезвычайных условиях:
17
 организацию и контроль исполнение решений о приоритетном использовании ресурсов сети связи и средств связи, сохранившихся в
зоне чрезвычайных ситуаций, либо о приостановлении или ограничении их использования, принимаемых федеральным органом исполнительной власти в области связи;
 мониторинг хода восстановления работоспособности сети связи и
средств связи в случаях их повреждения во время чрезвычайных
ситуаций природного или техногенного характера;
 подготовку и доведение до эксплуатационного персонала оперативных решений по обеспечению дополнительно возникающих потребностей в связи для нужд государственного управления, обороны страны, безопасности государства, обеспечения правопорядка;
 взаимодействие с органами всех уровней единой государственной
системы предупреждения и ликвидации чрезвычайных ситуаций в
ходе ликвидации последствий чрезвычайных ситуаций.
Центры управления сетями связи операторов связи размещаются на
территории Российской Федерации и взаимодействуют в порядке установленным Федеральным органом исполнительной власти в области связи:
 с центрами управления сетями связи специального назначения;
 с центрами управления системы централизованного управления сетью связи общего пользования;
 с центрами управления взаимодействующих сетей связи.
Управление сетью связи осуществляется на постоянной основе в круглосуточном режиме.
Внедрение централизованного сетевого управления в России, как и во
всём мире, сегодня затруднено, что определяется следующими факторами:
 разнообразие типов телекоммуникационного оборудования, эксплуатируемого на сетях операторов связи,
 различные средства технической эксплуатации и обслуживания;
 отсутствие у операторов связи достаточных финансовых средств на
приобретение дорогостоящих программно-аппаратных платформ
сетевого управления.
При внедрении современного комплекса сетевого управления оператор
связи получает следующие преимущества:
 повышается качество услуг связи и уровень технического обслуживания сети;
 оперативно обнаруживаются и устраняются неисправности и отказы;
 снижаются эксплуатационные расходы и появляются дополнительные доходы за счёт качественно новых услуг, а это создает предпосылки для дальнейшего расширения и модернизации сети;
 оператор связи может контролировать операторов, пользующихся
той же сетью связи на правах присоединения;
18
 оператор связи может контролировать техническое состояние и работоспособность как отдельных узлов, так и всей сети в режиме реального времени;
 оператор связи получает возможность контролировать абонентские
линии и управлять потоками вызовов, анализировать трафик, а также принимать обоснованные решения по вопросу номенклатуры
услуг, ценообразования, обслуживания сети.
Решение ряда перечисленных задач было частично осуществлено при
создании в 1980-1990-х годах центров технической эксплуатации оборудования (ЦТЭ) сетей связи. Создание ЦТЭ позволило накопить достаточный
практический опыт и усовершенствовать технологию удалённого контроля и
управления телекоммуникационным оборудованием.
В основе организации управления ЕСЭ лежат следующие принципы:
 интеграция функциональных, физических и информационных
структур управления;
 создание гибкой архитектуры на основе методологии открытых систем,
обеспечивающей возможность реконфигурации и развития системы
управления;
 стандартизация компонентов системы управления;
 повышение уровня автоматизации процессов управления;
 применение новейших информационных технологий.
В качестве теоретической базы для построения системы управления ЕСЭ
принимается концепция сети управления электросвязью TMN, которая в общем виде изложена в Рек. МСЭ-Т М.3010.
Организационно каждая система управления сетями (СУС) оператора
должна представлять территориально - разнесенную иерархическую структуру, построенную в соответствии с принципами TMN. Топология сетей управления
в пределах зоны ответственности оператора, размещение центров управления
(ЦУ), число уровней иерархии совокупно должно определяться в соответствии с
особенностями управляемых сетей, их назначением, размерами, разветвленностью, организацией технических средств.
Минимальное число уровней иерархии управления - два:
 на нижнем уровне находятся центры управления элементами сети
(ЦУ-ЭС), осуществляющие контроль и непосредственное взаимодействие с оборудованием связи;
 на верхнем уровне создаётся центр управления сетью в целом, с
возможностью управления услугами связи и бизнесом.
На разветвленных сетях связи, охватывающих большую территорию,
целесообразно создавать центры управления сетью на промежуточных уровнях. Системы управления сетями федерального значения, как правило, должны
иметь четырехуровневую структуру, включающую, кроме центра управления
сетью и услугами связи оператора на верхнем уровне иерархии и центр управления элементами на нижнем уровне иерархии, еще два подуровня управления
сетями (см. рис. 1.1):
19
 территориальный центр управления (ТЦУ), осуществляющий
функции по управлению сетью и услугами связи в зоне, определенной администрацией связи во взаимодействии с вышестоящим
ЦУ;
 узловой центр управления (УЦУ), осуществляющий управление
на части выделенной территории ТЦУ в непосредственном взаимодействии с ТЦУ.
Центральные органы
управления
Национальный центр
Системы управления операторов связи
федерального и регионального значения
Национальный центр
управления
ЕСЭ
управления
ВСС
РФ РФ
Центр управления сетью федеральный
Региональный центр
управления ЕСЭ РФ
ТЦУ- федеральный
Зональный центр
управления
ЕСЭ РФ
Центр управления сетью
- зональный
Узловой центр
управления федеральный
Местный центр
управления
ЕСЭ РФ
Центр управления
элементами сети местный
Центр управления
элементами сети зональный
Центр управления
элементами сети федеральный
Рис. 1.1 – Структурно-функциональная схема управления для
операторов сетей общего пользования
Системы управления зоновыми сетями должны иметь трех- или двухуровневую структуру Системы управления местными сетями, как правило,
должны иметь двухуровневую структуру управления. Системы управления
сетями оператора могут включать ряд подсистем управления различными видами сетей связи в зоне ответственности данного оператора. Центральные органы управления интегрируют все подчинённые системы управления в единую
АСУ ВСС РФ.
В каждой СУС оператора должен быть организован многофункциональный головной центр управления сетями (ЦУ оператора), который осуществляет контроль за состоянием сетей зоны оператора в целом, планирование
развития и предоставления услуг и сетей связи, взаимодействие с центрами
управления других операторов и соответствующими центральными органами
управления ВСС РФ.
Структура управления ВСС РФ и операторов связи представляет собой
сложную многоуровневую структуру с разнообразными функциональными
20
связями на всех уровнях. Создание и обеспечение работоспособности рассмотренной структуры требует не только организационно-технических, но
управленческих решений по реорганизации управления предприятием связи
(оператором) в целом. Это более высокий уровень управления, обсуждение
которого выходит за рамки настоящего учебного пособия. Далее рассматриваются в основном технические аспекты организации системы управления
сетями связи.
1.3 Управление в Глобальной информационной инфраструктуре GII
Глобальная информационная инфраструктура (Global Information Infrastructure, GII) по своему назначению и функциям аналогична ВСС РФ [32].
Основой GII являются существующие и строящиеся телекоммуникационные
системы и сети. Для предоставления услуг телекоммуникаций в GII используются многочисленные программно-аппаратные средства, которые позволяют пользователям обмениваться разными видами сообщений (речь, видео,
данные) в любое время по приемлемой цене и с заданным качеством. Средства GII позволяют унифицировать процедуры предоставления доступа к
услугам связи для жителей различных государств, а также организовать межсетевое взаимодействие сетей связи различных стран. Концептуально ВСС
РФ является частью GII.
Инфраструктура GII включает в себя 4 основных элемента :
Люди, которые являются источниками и получателями сообщений, а
также используют полученную информацию.
Информационные устройства (information appliances), которые используются для хранения, обработки данных и позволяют получать доступ к
информации.
Коммуникационная инфраструктура, которая осуществляет передачу
информации между географически удалёнными информационными устройствами. Информационная инфраструктура может быть представлена в виде
транспортной сети и сети доступа.
Информация, которая включает в себя видео, речь, данные, а также
прикладное программное обеспечение (пользовательские приложения), которое позволяет конвертировать сообщения из оригинальной формы (голос,
изображение, компьютерная графика) в электронную форму.
Взаимодействие перечисленных элементов показано на рис. 1.2.
21
ПЭВМ
Информация
Платформа
поддержки
приложений
Информация
Протоколы обмена
Платформа
поддержки
приложений
Платформа
поддержки
коммуникаций
Телекоммуникационная
сеть (сети связи)
Платформа
поддержки
коммуникаций
Информационные
устройства
Коммуникационная
инфраструктура
Информационные
устройства
Рис. 1.2 – Взаимодействие основных элементов GII
Примеры информационных устройств – персональный компьютер, рабочая станция в ЛВС, телефонный аппарат, телевизионный приёмник, факсимильный аппарат. В качестве платформы поддержки приложений могут
использоваться вычислительные средства в совокупности с операционными
системами, микропрограммное обеспечение информационных устройств,
прикладное программное обеспечение, специализированные процессоры, кодеки.
Платформы поддержки коммуникаций – это оконечное оборудование
данных, модемы, устройства доступа различного назначения. Примеры
средств доступа – абонентская линия связи до АТС, линия DSL-доступа,
сеть кабельного телевидения, оптическая линия доступа, канал радиосвязи,
спутниковый канал, линия радиодоступа. Примеры телекоммуникационной
сети – телефонная сеть связи общего пользования, первичная сеть связи, сеть
передачи данных различных стандартов (X.25, Frame Relay, ATM, MPLS),
сеть Интернет. Все перечисленные программные и аппаратные компоненты
GII, а также услуги, оказываемые на их основе, являются объектами сетевого
управления.
Структура GII связывает между собой в единое целое сетевые ресурсы,
устройства хранения и обработки данных, а также ресурсы промежуточного
уровня (middleware) с тем, чтобы предложить пользователям стандартные
услуги и поддержать индивидуальные пользовательские приложения. К
средствам middleware в рамках GII можно отнести средствам обеспечения
информационной безопасности, биллинг, а также средства сетевого управления и администрирования. Общая структура услуг GII показана на рис. 1.3.
22
Услуги IP-телефонии, службы передачи данных,
Услуги
интеллектуальные сети, службы Интернет
инфраструктурного уровня
(телесервисы, службы
связи)
Услуги
промежуточного
уровня
(middleware)
Услуги
базового уровня
(сети связи,
приложения
пользователя)
Биллинг
Безопасность
Поиск
данных
Аутентификация
Обмен данными
Телекоммуникационная сеть
(ТФОП, ATM, IP, MPLS)
Коммутатор
Модем
АТС
Сеть доступа
Телефон
Сеть доступа
Сеть доступа
ПЭВМ
Информационные
Кабельное ТВ
устройства
Рис. 1.3 – Уровни услуг GII
Спектр услуг, которые предлагаются GII, достаточно широк и может
динамический изменяться вместе с изменением доступных сетевых и информационных ресурсов. Поэтому целесообразно классифицировать компоненты
услуг. При этом каждый компонент услуги зависит от ресурса, необходимого
для поддержки услуги. Различают следующие компоненты услуги :
Инфраструктурные компоненты услуги (infrastructural service
components) – предоставляют возможности доступа к конечным информационным услугам (службам, телесервисам) для передачи речи через телефонную сеть, пересылки файлов через Интернет и т.п. Инфраструктурные компоненты могут также включать услуги компонент промежуточного и базового (baseware) уровня программного управления.
Компоненты услуг промежуточного (middleware) уровня – используются для обеспечения межсетевого взаимодействия и совместного функционирования нескольких приложений. Компоненты услуг промежуточного
уровня позволяют объединять компоненты услуг базового уровня и добавлять функциональность, которая необходима для предоставления всего набора инфраструктурных услуг.
Существует 4 категории услуг промежуточного уровня; в рамках
настоящего пособия интерес представляют категории M1 и М2.
23
Категория M1 – компоненты пакетизации и взаимодействия услуг.
Обеспечивают возможность объединения в пакет ряда инфраструктурных
услуг; поддерживают взаимодействие между различными системами GII.
Категория M2 – компоненты поддержки услуг промежуточного ПО.
Применяются для обеспечения коммуникационной функции GII и включают
:
 Компоненты услуг человеко-машинного интерфейса.
 Компоненты услуг регистрации (пользователя).
 Компоненты услуг аутентификации.
 Компоненты услуг обеспечения информационной безопасности.
 Компоненты услуг поиска информации.
 Компоненты услуг биллинга.
 Компоненты услуг управления услугами.
Компоненты услуг базового уровня поделены между компонентами
услуг сетей связи и компонентами услуг обработки и хранения данных. Соответственно, компоненты услуг связи используют сетевые ресурсы; компоненты услуг сбора и хранения информации используют ресурсы систем хранения и обработки данных.
Для базового уровня характерна «приближённость» услуг к функционированию в реальном времени, т.е. к оперативно-техническому управлению
оконечным соединением.
Логика управления на промежуточном уровне носит более общий характер и затрагивает вопросы контроля качества услуг связи, обеспечение
информационной безопасности и межсетевого взаимодействия. Далее рассматриваются интерфейсы взаимодействия между функциями управления и
другими функциями GII.
Под функцией понимается логический элемент, который выполняет заранее определённое задание в ответ на появление входного сигнала; в результате выполнения задания появляется определённый выходной сигнал или
информация.
Функции реализуются устройствами или компонентами устройств. Одна и та же функция, например установление исходящего соединения, может
осуществляться телекоммуникационными устройствами различных видов и
типов.
Логический интерфейс – это описание процедуры взаимодействия
между двумя функциями, включая формат информации, которая передаётся
между функциями и описание отклика на передачу информации. С точки
зрения технического устройства, реализующего ту или иную функцию, отклик означает срабатывание этого устройства.
В описание логического интерфейса включается описание протокола
взаимодействия и описание функциональной опорной точки (functional
reference point) обмена информацией.
24
Функциональная опорная точка описывает требования к интерфейсу
т.е. указывает, какие точно действия или операции должны быть доступны
при внешнем обращении или вызове функции.
Протокол содержит описание входных/выходных сигналов и последовательности обмена ими.
Логический интерфейс является реализацией функциональной опорной
точки, т.е. логический интерфейс описывает, как именно реализуется взаимодействие с данной функцией на уровне обмена информацией.
Стык между функциями свидетельствует о наличии информационного
взаимодействия на уровне протокола через соответствующий интерфейс.
Функции, функциональные опорные точки, логические интерфейсы
(стыки) в совокупности составляют функциональную модель GII.
Разработка функциональных моделей позволяют разработчикам определить, как будет функционировать тот или иной элемент GII и какие функции этот элемент будет выполнять. На рис. 1.4 показаны основные составляющие функциональной модели. Подразумевается, что функции взаимодействуют через логический интерфейс.
Форматы информации
Протокол взаимодействия
Функция
Функция
Рис. 1.4 – Функциональная модель
По форматом информации на рис. 1.4 понимается способ кодировки
данных в том или ином протоколе, например CORBA IDL, HyperText Markup
Language (HTML), способы цифрового кодирования речи и сжатия/оцифровки видеоизображения.
В GII существуют следующие виды функций :
Функции приложений (applications functions, AF) – описание прикладных задач пользователя, в частности, прикладных задач управления.
Функции промежуточного уровня (middleware functions, MF) – описание задач, которые решаются следующими функциями прикладного уровня:
 Функции контроля услуг (service control functions, SCF) – функции
промежуточного уровня, которые позволяют создавать услуги из
отдельных компонент и сетевых ресурсов; здесь же присутствуют
функции контроля за взаимодействием пользователя и услуги.
 Функция управления (management functions, ManF) – эта функция
реализует задачи управления всеми другими функциями.
Функции базового уровня (baseware functions, BF) позволяют функционировать прикладным функциям и функциям промежуточного уровня, обме25
ниваться сообщениями с другими функциями, используя для этого сетевые
функции и создавать интерфейс (точки взаимодействия) с пользователями.
Существует различные типы логических интерфейсов и протоколов для
организации взаимодействия между функциями (см. таблицу 1.1).
26
Таблица 1. 1– Назначение интерфейсов и стыков
Тип интерфейса или
протокола
Прикладной протокол AP
(Application Protocol)
Прикладной программный
интерфейс API
(Application Programming
Interface)
Протокол промежуточного
уровня MP
(Middleware Protocol)
Базовый программный
интерфейс BPI
(Basic Programming Interface)
Интерфейс человеккомпьютер
или человекомашинный интерфейс HCI (Human-Computer
Interface)
Опорная точка
сетей связи TRP
(Telecommunications
Reference Point)
Назначение стыка или интерфейса
Логический стык между прикладными
функциями.
Логический интерфейс между прикладными функциями и функциями промежуточного уровня, которые поддерживают
прикладные функции.
Логический стык между функциями прикладного уровня.
Логический интерфейс между функциями промежуточного уровня и функциями
базового уровня, которые поддерживают
функции промежуточного уровня (часто
эти интерфейсы относятся к API).
Логический интерфейс между пользователем и, главным образом, функциями
базового уровня; это не исключает возможности человекомашинного интерфейса к функциям промежуточного
уровня и к прикладным функциям.
Логический интерфейс между функциями базового уровня и сетевыми функциями.
На рис. 1.5 показаны функции управления различного уровня, взаимодействующие через соответствующие интерфейсы.
Интерфейсы 1,9  соответствуют опорным точкам транспортных
функций, которые «прозрачны» для других элементов, включая прикладные
протоколы, протоколы промежуточного уровня, средства контроля (оперативного управления) функциями базового уровня и функциями сетевого
контроля (network control functions).
Интерфейс 2  соответствует опорным точкам транспортных функций,
которые обеспечивают обмен информацией между функциями сетевого контроля и функциями базового уровня.
Интерфейс 3  соответствует опорным точкам транспортных функций,
которые «прозрачны» для всех типов протоколов.
Интерфейс 4  опорная точка между функцией базового уровня и
функциями оперативного управления сетью (контроль сети). Интерфейс 4
27
позволяет предоставлять услуги связи и независимо от технических средств
реализации транспортной функции.
10
Функции управления
5
Функции базового
и промежуточного
ПО
9
8
Функции базового
и промежуточного ПО
4
Транспортные
функции
1
Функции
базового и
промежуточного ПО
3
Функции управления
5
Функции управления
оборудованием в
реальном времени
2
5
Функции управления
услугами связи в
реальном времени
Транспортные
функции
6
7
Функции
базового и
промежуточного ПО
Прикладные
функции
Прикладные
функции
Пользователь
Рис. 1.5 – Примеры функций и логических интерфейсов в GII
Интерфейс 5  опорная точка сетевого управления. Имеет множество реализаций,
осуществляет управление в целом всеми функциями, не зависит от транспортной функции.
Интерфейсы 6,7,8  реализуются с помощью протоколов промежуточного уровня, которые передаются с помощью сетевой функции.
Интерфейс 10  протокол сетевого управления (management protocol),
который осуществляет обмен данными между функциями сетевого управления.
В функциональной модели GII обозначены опорные точки и соответствующие интерфейсы управления. Для реализации задач сетевого управления в рамках ЕСЭ РФ, как составной части GII, необходимы опорные точки и
интерфейсы различного назначения, которые позволяют реализовать следующие виды взаимодействия :
 взаимодействие между функциями GII;
 взаимодействие пользователя и GII;
 взаимодействие между различными функциями управления.
Описание реализации перечисленных функций, опорных точек и интерфейсов в рамках концепции TMN приводится в разделах 2 и 3.
28
1.4 Контрольные вопросы к разделу 1
1. Какие сети являются объектом управления в телекоммуникациях?
2. Какие общие задачи решает система управления телекоммуникационными сетями и системами?
3. Чему равно минимальное число уровней управления федерального оператора связи?
4. Дайте определение понятию «Глобальная информационная инфраструктура»
5. Укажите назначение логического интерфейса ГИИ.
6. Что такое функциональная модель?
7. Какие интерфейсы ГИИ можно использовать для сетевого управления?
29
РАЗДЕЛ 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:
«Открытая система - это система, реализующая открытые спецификации на интерфейсы, службы и форматы данных, достаточные для того, чтобы
обеспечить:
 возможность переноса (мобильность) прикладных систем, разработанных должным образом, с минимальными изменениями на
широкий диапазон систем;
 совместную работу (интероперабельность) с другими прикладными системами на локальных и удаленных платформах;
 взаимодействие с пользователями в стиле, облегчающем последним переход от системы к системе (мобильность пользователей)».
30
Открытая система есть абстрактное описание физических объектов.
Поэтому открытая система может быть представлена любым типом телекоммуникационного оборудования – АТС, маршрутизатором, сервером доступа в
Интернет, абонентским терминалом и т.п. Все перечисленные устройства
можно рассматривать как открытые системы, если они удовлетворяют приведённому определению.
Ключевой момент в определении открытых систем – использование
термина «открытая спецификация». Здесь и далее под «спецификацией» понимаются требования, предъявляемые к системе. Спецификация включает
упорядоченное описание параметров и структуры объекта или интерфейса; в
таком описании обязательно присутствует определение основных терминов,
используется определённый метод описания объекта и содержатся указания
на взаимосвязь данного объекта с другими объектами.
Открытая спецификация определяется как «общедоступная спецификация, которая поддерживается открытым, гласным согласительным процессом, направленным на постоянную адаптацию новой технологии, и соответствует стандартам».
Отсюда следует, что спецификация, к примеру, того или иного интерфейса для управления сетями связи вводят безотносительно к конкретным
программно-техническими средствам реализации этого интерфейса. Данный
вопрос подробно обсуждается в главе 6, где рассматриваются различные интерфейсы сетевого управления.
Как следует из определения, сущность технологии открытых систем
состоит в обеспечении переносимости (portability) прикладных программ
между различными компьютерными платформами или устройства телекоммуникаций при сохранении взаимодействия (interoperability) таких систем
друг с другом. Технически это достигается за счет использования стандартизованных программных и аппаратных интерфейсов между компонентами
(уровнями) открытых систем.
С позиций перечисленных уровней модель ВОС, обозначаемая в англоязычной литературе как ISO/RM (Open System Interconnected / Reference
Model), на сегодняшний день является достаточно проработанной с точки
зрения функциональности, полноты набора стандартов, определения совместимости стандартов друг с другом. Модель основана на разбиении среды на
семь уровней (рис. 2.1).
Каждый уровень соответствует подсистеме с определёнными функциями обработки информации.
31
Открытая система А
О бласть взаимодействия открытых систем
Прикладной
уровень
Сущность
SAP
Представительный уровень Сущность
Сеансовый
уровень
Транспортный
уровень
Прикладной
уровень
SAP
Сущность
SAP
Сущность
SAP
Сущность
SAP
Канальный
уровень
Сущность
SAP
Физический
уровень
Сущность
Ассоциация между
сущностями
Открытая система Б
Протокол
прикладного
уровня
Сущность
Протокол
представительного
уровня
Сущность
Протокол
сеансового
уровня
Сущность
Протокол
транспортного
уровня
Сущность
Протокол
сетевого
уровня
Сущность
Протокол
канального
уровня
Сущность
Протокол
физического
уровня
Сущность
Прикладной
уровень
SAP
Представительный уровень
SAP
Сеансовый
уровень
SAP
SAP
SAP
Транспортный
уровень
Сетевой
уровень
Канальный
уровень
SAP
Физический
уровень
Физическая среда распространения
Межсистемное взаимодействие
Рис. 2.1 – Модель взаимодействия открытых систем ISO
На прикладном уровне (application layer) работают приложения, с которыми имеет дело пользователь, например, выполнение вычислительных задач, поиск сведений в базе данных или в каталогах и т.п. Этот уровень не
предоставляет своих услуг другим уровням модели ВОС. На прикладном
уровне осуществляется взаимодействие прикладных процессов.
На уровне представления (presentation layer) обеспечивается возможность перекодировки информации прикладного уровня в единый формат, который принят в данной системе обмена. На этом уровне, при необходимости,
осуществляется шифрование данных.
На сеансовом уровне (session layer) организуется диалог между уровнями представления, т.е., по сути, диалог (сессия, или сеанс) между прикладными задачами высшего уровня; на этом же уровне осуществляется управление сессией и ее прерывание.
На транспортном уровне (transport layer) осуществляется разбиение
данных на пакеты с целью последующей передачи в узлы назначения. При
этом передача сообщения от сеансового уровня на транспортный осуществляется через точку доступа к услуге (Service Access Points, SAP), которая
называется также портом. Каждый порт имеет свой номер; начало сеанса связи означает занятие порта в исходящем узле, а о наличии соединения свидетельствует занятый порт на входящем узле.
На сетевом уровне (network layer) осуществляется соединение двух открытых систем с выбором маршрута установления соединения через сеть
связи, соединяющей эти системы. Выбор маршрута может осуществляться с
помощью специальных пакетов данных или самим пакетом.
32
На уровне канала данных (data-link layer) осуществляется передача
данных через канал связи или канал передачи. При этом к пакету могут быть
добавлены служебные поля для обеспечения физической адресации, контроля целостности данных; в качестве служебной информации добавляется
порядковый номер, а также биты, разделяющие пакеты. В итоге формируются кадры, которые поступают на физический уровень. Перечисленные функции канального уровня могут быть физически реализованы на сетевом интерфейсном модуле/карте (Network Interface Card, NIC).
На физическом уровне (physical layer) осуществляется физическое соединение узлов сети при побитовой передаче кадров между узлами. Данный
уровень определяет тип среды передачи, кодирование данных, методы передачи.
Физическая среда распространения обеспечивает перенос электрического или оптического сигнала (по медным или оптическим кабелям связи,
радиоэфиру и т.п.).
Разбиение на уровни обеспечивает «прозрачность» взаимодействия
между уровнями как внутри данной системы, так и между уровнями различных открытых систем. Поэтому модель ВОС в большей степени относится к
области коммуникационных взаимодействий между различными системами
и детально не рассматривает взаимодействие элементов «внутри» данной системы. Коммуникационное взаимодействие означает не только обмен информацией, но и взаимодействие нескольких систем для достижения определённых целей, например при распределённых вычислениях.
В описании модели ВОС содержатся определения таких важных понятий для сетевого управления, как сервис (service), интерфейс (interface) и
протокол (protocol).
Сервисы, или услуги определяют функциональность соответствующего уровня модели ВОС и могут быть предоставлены для вышестоящих
уровней модели ВОС со стороны нижестоящих уровней. В этом случае нижестоящий уровень является поставщиком услуг или служб для вышестоящего уровня.
Интерфейс определяет способ взаимодействия сущностей, принадлежащих двум смежным уровням одной открытой системы. Интерфейсы определяют правила передачи информации между уровнями и сигналы управления передачей, которые называются примитивами (primitives). В частности, в
[5] говорится о примитивах запроса, примитивах ответа и т.п. В дальнейшем,
учитывая, что интерес представляют приложения модели ВОС, будут использоваться термины «запрос», «ответ», «индикация».
Протокол отражает логику взаимодействия одноранговых (одноуровневых) сущностей при реализации ими определённого сервиса и описывает
форматы данных, которыми обмениваются сущности. Каждый протокол имеет свою версию и свой идентификатор, который передаётся при связи между
уровнями. Сущности могут принадлежать различным открытым системам.
33
Под сущностью (entity) понимается активный элемент внутри уровня
ВОС, который обладает набором функциональных возможностей, определенных для данного уровня. В качестве физических аналогов сущности могут
рассматриваться программы управления связью межу приложениями, программы разбиения информации на кадры и т.п. На данном уровне модели
ВОС может быть несколько сущностей. Понятие сущности используется
преимущественно для описания взаимосвязи открытых систем. В модели
ВОС существует ещё понятие «прикладная сущность» [4], или прикладной
процесс (аpplication process); это понятие относится к физическим объектам,
которые удовлетворяют определению открытой системы. Прикладные процессы реализуют обработку информации в ручном режиме ввода и управления в виде выполнения компьютерных программ, с помощью дистанционного контроля (вывод аварийных сигналов АТС на компьютер в центре технической эксплуатации). Содержательное описание прикладных процессов в
интеллектуальных сетях применительно к обработке сообщений протокола
INAP содержится в [1]. Поэтому сущность в модели ВОС является абстрактным представлением функций, присущих данному прикладному процессу.
Как уже отмечалось, в модели ВОС нижестоящие уровни (уровни N)
предоставляют сервисы вышестоящим уровням (уровням N+1). Сервисы
обеспечиваются за счёт функций, реализованных на уровне N, включая также
функции остальных уровней N-1. Предоставление сервисов осуществляется
по запросу уровня N+1. Таким образом, сервисы запрашиваются и предоставляются между смежными уровнями; «перескочить» через уровень N и
сразу запросить услуги уровня N-1 или N-2 нельзя. Сервисы предоставляются через упомянутую выше SAP. Эти точки имеют индивидуальные адреса,
которые запрашиваются уровнем N+1 при организации доступа к уровню N.
Соединения между уровнем N+1 и сервисами уровня N также имеют индивидуальные идентификаторы. Взаимодействие между уровнями обслуживается с помощью функций маршрутизации. Благодаря описанному взаимодействию осуществляется обмен между уровнями ВОС, а также между различными открытыми системами (см. рис.2.1), этот обмен называется ассоциацией (association), или связью между подсистемами.
Связь, или ассоциация между сущностями, т.е. между уровнями открытых систем, может осуществляться как с установлением, так и без установления соединения в режиме дуплекс, симплекс или полудуплекс. Для установления связи между уровнями N+1 могут использоваться протоколы, сервисы
и интерфейсы нижестоящих уровней, начиная с уровня N вплоть до физической среды распространения сигнала. В случае связи с установлением соединения имеются три фазы процесса: установление соединения, передача данных и разъединение. Установление соединения предпочтительно для тех систем, которые находятся в постоянном информационном обмене (соединение АТС в телефонной сети, передача данных между узлами). Режим установления соединений физически реализуется как соединение абонентов А и
Б в телефонной сети с коммутацией каналов. С другой стороны, если осу34
ществляется обмен эпизодической или нерегулярной информацией, то целесообразно рассматривать режим без установления соединения. Этот режим
можно применять, в частности, для широковещательной рассылки данных
сразу многим системам, а не только заданной системе.
Обмен информацией между уровнями ВОС осуществляется с помощью
протокольного блока данных (Protocol Data Unit, PDU), который состоит из
данных пользователя рис. 2.2.
(N) - PDU
Уровень N
(N-1) - SDU
(N-1) - PCI
(N-1) - PDU
Уровень N - 1
Рис. 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, который по сути является заголовком.
2.2 Основные понятия и принципы управления ВОС
Основные правила управления ВОС (OSI management framework) описаны в документе ISO/IEC 7498-4: Basic Referens Model, Part 4, Management
Framework (Базовая эталонная модель. Часть 4. Структура управления).
Предлагаемая модель управления является развитием идеи общей семиуровневой модели взаимодействия открытых систем для случая, когда одна система управляет другой, т.е. имеются управляющая и управляемая система.
В целом стандарт ISO 7498 публиковался и согласовывался по частям с
1984 г. по 1989 г. В 1994 г. стандарт пересматривался и претерпел некоторые
35
технические исправления и редактирование. В настоящее время представленная в документах ISO 7498 и в соответствующей Рек. МСЭ-Т X.200 модель взаимодействия открытых систем играет роль одного из фундаментальных стандартов в области информационных технологий. В Рек. X.200 определены базовые понятия, структура, семантика, механизмы исполнения, телекоммуникационной функции, т.е. функции, обеспечивающие взаимосвязь
удаленных систем посредством обмена данными, в том числе и с целью
управления.
В состав стандарта ISO 7498 входят документы, указанные в табл. 2.1.
Таблица 2.1– Перечень стандартов управления ИСО ВОС
Код документа
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)
Год ввода в
действие
1984
1994
1987
1994
1989
1991
1989
1994
1989
1992
Документ ISO/IEC 7498-4, касающийся основных правил управления, состоит из следующих основных разделов:
 термины и общие определения концепции управления;
 модель управления системами;
 информационная модель;
 функциональные области управления системами.
Документ ISO/IEC 7498-4 определяет пять основных областей, являющихся объектами функционального управления: управление неисправностями, регистрация данных управления, управление конфигурацией, производительностью и безопасностью. С учётом содержания ISO/IEC 7498-4 можно
указать ряд стандартов, относящихся к управлению открытыми системами
(табл. 2.2).
Важное значение имеет Рек. МСЭТ X.290 (ISO/IEC 9646), в которых
определена методологическая основа тестирования соответствия разработанных вариантов сетевых протоколов стандартам модели ВОС. При таком тестировании последовательно определяются: основные понятия, типовая
структура процесса установления соответствия протоколов стандартам ВОС,
абстрактные методы тестирования, средства спецификации возможных ситу36
аций при тестировании, структура комплексов тестов, назначение и функции
лабораторий тестирования.
Таблица 2.2 – Перечень стандартов управления ИСО CMIS
Код рекомендации
ISO/ITU
ISO 9595 / X.710
ISO 9596-1 / X.711
ISO 10040
ISO 10164
ISO 10165
ISO 10165-1 DIS
ISO 10165-2 DIS
ISO 10165-4 DIS
ISO 10733 CD
ISO 10737 CD
Название рекомендации
Общие услуги информации управления
(Common Management Information Services,
CMIS)
Общий протокол информации управления
(Common Management Information Protocols,
CMIP)
Обзор управления системами
(Systems Management Overview, SMO)
Управление системами
(Systems Management)
Структура информации управления
(Structure of Management Information)
Информационная модель управления
(Management Information Model)
Определения информации управления
(Definition of Management Information)
Общее определение объектов управления
(Guidelines for the Definition of Managed Objects)
Элементы информации управления, относящиеся к стандартам сетевого уровня модели ВОС
(Elements of Management Information Related to
OSI Network Layer Standards)
Элементы информации управления, относящиеся к стандартам транспортного уровня модели
ВОС (Elements of Management Information Related to OSI Transport Layer Standards)
С точки зрения семиуровневневой модели ВОС вводятся следующие
базовые понятия управления открытыми системами:
 управление приложениями (application management) – функции
прикладного уровня для управления прикладными процессами модели ВОС;
 ресурсы ВОС  вычислительные ресурсы для обработки данных и
сетевые ресурсы коммуникации, которые имеют отношение к открытым системам;
 управление системами (systems management)  функции прикладного уровня, относящиеся к управлению различными ресурсами
(объектами) и их состоянием на всех уровнях модели ВОС;
37
управление уровнем (layer management)  функции, относящиеся к
управлению уровня N согласно протокола уровня N (например, активизация некоторых функций и контроль ошибок) и некоторые
функции управления системами. Управление уровня N использует
коммуникационные протоколы нижних уровней.
В модели ВОС необходимо распознавать ситуации, связанные с инициализацией, завершением и текущим контролем (мониторингом) различных
действий, а также обеспечивать координацию различных операций, например
при обработке нештатных условий функционирования системы. Перечисленные процедуры можно отнести к различным функциональным областям
управления открытых систем. Операции уровня N, осуществляемые в ходе
управления, предусматривают обмен информацией между открытыми системами. Соответственно, стандартизуются только те протоколы, которые имеют отношение к информационному обмену, поэтому протоколы модели ВОС
называют коммуникационными (communications protocol). Прочие действия
по управлению в рамках модели ВОС детально не рассматриваются.
Управление системой и управление уровнями предполагают поддержку режима работы без установления соединения между системами. В результате характеристика, тип и содержание услуги уровня N, которая предоставляется в режиме без установления соединения, может быть передана на вышестоящий уровень до непосредственного вызова данной услуги.
Управление приложениями затрагивает прежде всего прикладные процессы ВОС и осуществляется на прикладном уровне. Можно указать следующие операции управления приложениями:
 инициализация параметров прикладных процессов на физическом прототипе открытой системы;
 инициализация, эксплуатация и завершение использования прикладных процессов;
 назначение и отмена использования ресурсов модели ВОС для
прикладного процесса;
 обнаружение и предотвращение блокировок ресурсов ВОС;
 контроль целостности системы и её данных;
 контроль безопасности системы и её данных;
 контроль восстановления системы после повреждений.
Управление системой включает в сферу своей деятельности ресурсы
модели ВОС на всех уровнях. Можно привести следующий список операций
управления системой, который, однако, не является исчерпывающим.
1. Активизация и деактивизация управления, которая включает следующие операции:
 активация, эксплуатация и завершение использования ресурсов
модели ВОС на всех уровнях, включая физическую среду распространения сигнала;
 загрузка программного обеспечения;

38
 установление, поддержка и разъединение соединений между
управляемыми сущностями;
 инициализация параметров открытых систем и/или их модификация.
2. Мониторинг, или текущий контроль, который включает сообщения:
 о состоянии системы или об изменении состояния;

о статистике состояний системы.
3. Контроль ошибок, который включает:
 обнаружение ошибок и некоторые функции диагностики ошибок;
 реконфигурацию системы и перезагрузку (рестарт) системы.
Управление уровнями открытой системы осуществляется в двух
направлениях: это активизация, во – первых, функций уровня и контроль
ошибок, вовторых, функций управления уровнем, которые являются подмножеством управления системой.
Функции управления открытыми системами допускают как централизованное, так и децентрализованное управление. Модель ВОС напрямую не
указывает степень централизации функций управления. При реализации системы управления возможно управление как из единого центра, так и на
уровне каждого узла. Например, возможно централизованное или децентрализованное управление телефонной нагрузкой на сетях связи общего пользования. Кроме того, даже если данная открытая система непосредственно не
взаимодействует с другими открытыми системами, то для управления можно
устанавливать соединения между элементами невзаимодействующих открытых систем и осуществлять передачу сигналов управления.
2.3 Функциональные области и функции управления
Стандарты управления открытыми системами обеспечивают единый
подход к решению разнообразных задач сетевого управления. В Рек. МСЭ-Т
X.700, основанной на принципах семиуровневой модели ВОС, определены
следующие функциональные области (functional areas):
 управление неисправностями/последствиями отказов (fault management);
 управление конфигурацией (configuration management);
 управление расчетами за услуги (accounting management);
 управление рабочими характеристиками/производительностью
(performance management);
 управление безопасностью (security management).
Перечисленные функциональные области иногда совместно обозначаются как FCAPS (по первым буквам англоязычных обозначений). Функциональная область управления определяет, какие ресурсы в данной системе являются управляемыми, т.е. указывает ресурсы, которые могут целенаправленно изменяться для достижения цели управления в процессе существова39
ния и функционирования системы.
Требования, предъявляемые со стороны пользователей и разработчиков
к реализации перечисленных функциональных областей, отражаются в соответствующих спецификациях через функции управления системами (Systems
Management Function, SMF),которые реализуются за счёт сервисов или услуг
управления на соответствующем уровне модели ВОС. Все перечисленные
функциональные области и соответствующие им SMF применяются в TMN.
Далее в настоящем разделе приводятся список и характеристики SMF, описывается каждая функциональная область и относящиеся к ней SMF. После
описания SMF даются характеристики функциональных областей управления.
Функция управления объектом (object management function) cогласно
Рек. МСЭ-Т X.730 включает описание базовых услуг по управлению объектом. Под объектом понимается открытая система либо её элемент, вплоть до
отдельной сущность. Базовые услуги реализуются через функции протокола
общего протокола информации (Common Management Information Protocol,
CMIP).
Базовые функции управления объектами, определённые в Рек. МСЭТ
Х.730, определяют услуги, обеспечивающие манипулирование управляемыми объектами. Эти услуги условно можно разделить на два множества:
 услуги, которые относятся к общим услугам информации управления (CMIS);
 услуги, которые обеспечивают дополнительные возможности по
сравнению со CMIS.
Первая категория услуг используются для создания, удаления объектов
управления, т.е. выполнения действий типа «установить», «получить», «выполнить», «активизировать». С помощью услуг первой категории можно генерировать сообщения о событиях. Услуги второй категории состоят из дополнительных сервисов, связанных с генерацией сообщений о функционировании объектов управления, в частности об изменении состояния атрибутов
объектов. Функция управления объектом не включает расширенное управление состоянием объекта, которое согласно Рек. МСЭ-Т X.731 определено
функцией управления состоянием (state management function), а определяет
механизм контроля за объектом, включая мониторинг состояния и изменения
состояния объекта, команды для изменения состояния объекта.
Управление состоянием объекта прежде всего определяет стандарты
представления текущего состояния объекта, которое может изменяться под
воздействием системы управления. Функции управления состоянием объекта
обеспечивают стандарты управления объектом на протяжении всего его
жизненного цикла.
Существуют три функциональные области управления состояниями:
 определение работоспособности устройства (operability), которое
определяется наличием или отсутствием ресурсов, доступных для
управления. Соответственно с точки зрения работоспособности
40
возможны два состояния объекта: разрешение (enabled) и запрет
(disabled) управления ресурсами;
 использование, или загрузка устройства (usage), которое определяет, находится ли устройство под рабочей нагрузкой, а также позволяет судить о наличии свободных ресурсов. С точки зрения загрузки возможно три состояния объекта управления: свободен (idle), активизирован/задействован (active), используется интенсивно (busy);
 административное состояние, которое описывает возможность использования тех или иных ресурсов. Это состояние также делится
на три фазы: доступ к ресурсам заблокирован (locked), ресурсы доступны (unlocked), режим выключения или остановки (shutting
down). При этом ресурсы могут быть заблокированы, но возможность управления сохраняется. К примеру, состояние административной блокировки наступает в случае ввода неправильного пароля
доступа пользователя к системе управления.
Каждое из перечисленных состояний управляемых объектов обладает
различными характеристиками, которые выражаются через атрибуты; при
этом атрибуты, характеризующие работоспособность и загрузку устройств,
должны быть удобочитаемы для пользователя системы управления. Атрибуты, характеризующие административное состояние, должны быть доступны
для изменения со стороны управляющей системы.
Функция управления взаимосвязями объектов (relationship management
function) согласно Рек. МСЭ-Т X.732 определяет способы взаимодействия
между управляемыми объектами. В частности, с помощью этой функции
можно определить, какой объект посылает управляющие команды, а какой
объект эти команды принимает и выполняет.
Функция сообщения о неисправностях (alarm reporting function) согласно Рек. МСЭ-Т X.733 определяет механизм генерации и передачи сообщений
о неисправностях. Этот механизм также включает предупреждение об обнаружении о неисправности. Предупреждение содержит характеристики, которые включают детальное описание природы аварийной ситуации, а также
возможные причины её появления. Сообщение о неисправностях выдаётся с
использованием CMIS и функционирует в режиме с подтверждением или без
подтверждения. Информация, которая используется для характеристики повреждений, включает в себя следующие градации аварийной ситуации:
 критическая неисправность (crtitical alarm);
 серьёзная неисправность (major alarm);
 незначительная неисправность (minor alarm);
 предупреждение о возможной неисправности (warning);
 неопределённая неисправность (indeterminate);
 устранённая неисправность (cleared).
Каждый из перечисленных видов неисправности характеризуется
определёнными критериями, выполнение которых приводит к появлению
определённого типа аварийного сообщения. В частности, вывод из строя не
41
менее 50% оборудования узла коммутации или передачи характеризуется как
критическая неисправность. К таким же последствиям может привести,
например, потеря электропитания на стативах или перезапуск программного
обеспечения, приводящий к потере всех текущих соединений. Предупреждение может быть выдано в случае принудительного изменения системной даты на узлах коммутации с программным управлением, так как данное действие приведёт к изменениям содержания полей даты и времени в файлах с
данными об оказанных услугах связи. В каждом из описанных видов сообщений указываются координаты модулей и устройств, в которых обнаружены повреждения, а также возможные причины выдачи аварийного сообщения, например потеря синхронизации.
Среди причин появления аварий можно выделить следующие:
 ошибка интерфейсного модуля (линейного комплекта);
 ошибка прикладного программного обеспечения;
 ошибка процесса установления соединения;
 ошибка протокола сигнализации;
 перегрузка;
 повреждение данных системы;
 потеря синхронизации;
 запуск недопустимой версии программного обеспечения;
 ошибка внешних систем;
 недопустимая вибрация (например, при землетрясении);
 пожар;
 перегрев или переохлаждение оборудования и т.д.
Функция управления событиями (event management function) согласно
Рек. МСЭ-Т X.734 обеспечивает механизм управления распределением сообщений о происходящих сетевых событиях, например, сообщений об аварийных ситуациях, о ликвидации аварии, извещений о запуске новой системы и т.п. Все без исключения сообщения могут поступать к оператору системы управления, а сообщения о серьёзных и критических неисправностях на рабочее место руководителя центра управления.
Управление событиями можно рассматривать как один из ключевых
элементов систем управления по стандартам ВОС. Управление событиями
контролирует распределение сообщений о произошедших в системе событиях по всей системе управления. В Рек. МСЭ-Т X.734 определено несколько
способов распределения сообщений о событиях. В основе схемы распределения сообщений о событиях находятся дискриминаторы пересылки сообщений (Event-Forwarding Discriminators, EFD). Эти дискриминаторы представляют собой объекты, которые могут использоваться для определения интервала (кванта) времени для передачи сообщения, режима передачи (с подтверждением или без подтверждения получения сообщения), а также получателей сообщений о событиях в системе. Дискриминаторы могут использоваться для подавления вывода на экран оператора системы управления ин42
формации о второстепенных неисправностях. Эти сведения могут направляться напрямую в журнальный файл с данными о повреждениях (архив повреждений), т.е. в log-файлу (файл регистрации).
Основные технологии передачи сообщений о событиях включают сценарии, с помощью которых система управления осуществляет контроль параметров, и время использования EFD на управляемых объектах, где поддерживается CMIP.
Функция управления журналированием, или регистрацией (log control
function) согласно Рек. МСЭ-Т X.735 обеспечивает запись информации об
управлении в отдельный файл. Это могут быть записи в текстовом формате,
например заголовки и содержание аварийных сообщений, а также запись
управляющих команд, которые были введены оператором.
Управление журналированием определяет способы, которыми в системе управления поддерживается фиксация сведений обо всех событиях в системе. Услуги по журналированию в какой-то степени аналогичны услугам
по управлению событиями. Управление журналированием подразумевает
наличие механизма сохранения данных о событиях в системе. К примеру, это
означает формирование в системе управления упомянутого выше log-файла,
в котором фиксируется информация о неисправностях, данные о происшедших событиях, результаты тестов отдельных модулей и общесистемных тестов, команды, поступившие от операторов. Перечисленные сведения фиксируются в log-файлах в виде текстовых сообщений или с помощью кодов сообщений.
Управление журналированием предусматривает наличие механизма
изменения критериев формирования log-файла, а также средства восстановления и удаления регистрационных записей.
Сообщение о нарушениях безопасности (security alarm reporting) согласно Рек. МСЭ-Т X.736 определяет услуги по перенаправлению и отбору
сообщений, связанных с уведомлениями о критических режимах нарушения
безопасности данных системы управления. Указанные критические события
в первую очередь выражаются с помощью аварийных сигналов безопасности
(security alarms). Аварийные сигналы оповещают систему управления о потенциальных нарушениях в системе безопасности и включают сигналы об
общем или эксплуатационном нарушении безопасности (например, запрещённые операции с программным обеспечением), физическом нарушении
безопасности (несанкционированном проникновении в помещение АТС, физической порче компьютеров или их элементов).
Кроме того, функция генерации аварийных сигналов безопасности
включает идентификацию возможных причин нарушений безопасности. Следует отметить, что вышесказанное относится прежде всего к механизму генерации сообщений о наличии проблем с безопасностью. Техника определения и фильтрации (отбора для обработки) аварийных сигналов безопасности
рассматривается отдельно каждым разработчиком.
43
Тестовые (диагностические) и конфиденциальные классы объектов
управления (confidence and diagnostic test classes) согласно Рек. МСЭ-Т X.737
определяют услуги и объекты, которые могут использоваться при управлении тестами системы и генерации сообщений о результатах тестов.
Функция суммирования результатов (summarization function) согласно
Рек. МСЭ-Т X.738 определяет структуру, правила генерации, содержание,
порядок выдачи отчётов с обобщённой информацией о системе.
Функция мониторинга загрузки (workload monitoring function) согласно
Рек. МСЭ-Т X.739 определяет услуги по управлению и контролю загрузки
системы.
Как уже отмечалось выше, управление взаимосвязями объектов определяет способы, которыми объекты воздействуют один на другой. Это относится, в первую очередь, к взаимодействию системы управления и управляемого объекта. Согласно Рек. МСЭ-Т X.732 существуют несколько стандартных способов взаимодействия объектов, которые подразделяются на взаимодействия:
 для оказании услуг (service);
 одноуровневых приложений (peertopeer);
 при нейтрализации неисправности (fallback);
 при дублировании или резервировании (backup);
 при группировке объектов (group).
Например, взаимодействие одноуровневых приложений может относится к двум объектам, которые достаточно регулярно обмениваются информацией и находятся на одном и том же уровне N, но в различных открытых
системах. В случае, когда появляется новый управляемый объект, который
должен взаимодействовать с системой управления, перечисленные стандартные способы взаимодействия используются для обеспечения перекрёстных ссылок на уже существующие управляемые объекты.
Общее требование ко всем функциональным областям управления
состоит в том, что вид управления определяется причиной происходящих
на сети событий, т.е. управление инициируется посредством сообщений о
событиях на сети. Другими словами, управление не происходит самопроизвольно, переход от одного процесса или процедуры управления к другой
всегда обусловлен воздействием какого-то внутреннего или внешнего события. Под внешним событием понимается, например, потеря электропитания,
пожар или затопление помещения. Под внутренним событием понимается, к
примеру, истечение предельного времени выполнения определенного задания или теста, сбой программного обеспечения, выход из строя функционального модуля.
2.4 Характеристика функциональных областей
Управление неисправностями (fault management)
44
характеризуется
прежде всего функцией генерации специфических сообщений о неисправностях – так называемых тревог (alarms). При этом осуществляется регистрация источника сообщений об ошибке и начинается тестирование сетевых ресурсов с тем, чтобы идентифицировать и контролировать неисправности. При управлении неисправностями необходимо предпринимать действия по наблюдению за неисправностями (анализ, фильтрация и корреляция сообщений о неисправностях), выполнять тестирование неисправного
ресурса, обеспечивать локализацию неисправности, а также исправлять неисправности.
Основное требование к управлению неисправностями – это наличие
операций (процедур) управления, инициируемых определенными сетевыми
событиями. Кроме того, необходимо четко определить основные и второстепенные тревоги и установить правила тестирования. Соответствующие
SMF – это сообщений о событиях (event reporting) согласно Рек. МСЭ-Т
X.734, журналирование сообщений (logging) согласно Рек. МСЭ-Т X.735,
сообщение о неисправности (тревоге) согласно Рек. МСЭ-Т X.733 и тестирование согласно Рек. МСЭ-Т X.737, X.745.
Управление конфигурацией (сonfiguration management) обеспечивает
инициализацию (запуск), установку и обеспечение функционирования оборудования связи. Это позволяет осуществлять в едином комплексе работы по
пуско-наладке оборудования и передачу информацию о состоянии оборудования по запросу администратора сети. Появляется техническая возможность
обеспечивать средства технического учета оборудования и поддерживать
уведомления об изменениях конфигурации оборудования через соответствующие сообщения.
Основные требования к управлению конфигурацией: наличие операций (действий) над объектами управления, которые зависят от определенных событий; контроль изменений конфигурации, контроль первичного состояния ресурсов сети; представление связей и взаимоотношений между
объектами управления в форме, понятной для разработчика системы управления и пользователя; возможность планирования сети; управление временем; распределение программного обеспечения и наличие средств восстановления системы. Соответствующие 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) за услуги связи - это
совокупность процедур учета информации о количестве оказанных услуг
связи и обработки зафиксированных данных в целях подготовки счетов с
45
начислениями за услуги связи. Применение управления расчетами должно
дать возможность оператору установить обоснованную плату за использование сетей и оборудования связи, определить себестоимость многочисленных услуг связи.
Ключевые требования к управлению расчетами - наличие операций
(действий над объектами), зависящих от событий, в особенности регистрация услуг и основные правила регистрации (фиксации) использования
услуг (usage metering) связи или сетевого ресурса. Соответствующие SMF –
сообщения о событиях согласно Рек. МСЭ-Т X.734, регистрация событий
согласно Рек. МСЭ-Т X.735 и измерения использования ресурсов для
начислений (accounting metering) согласно Рек. МСЭ-Т X.742.
Управление рабочими характеристиками и производительностью
(performance management) сети предполагает наличие и доступность информации управления с целью определения технического состояния сети и загрузки системы связи при естественных и искусственных, т.е. смоделированных условиях. Управление рабочими характеристиками сети поддерживает совокупную информацию об эффективности работы сети, которая поступает периодически, обеспечивая тем самым статистику работы сети, и
позволяя планировать различные управляющие воздействия.
Для управления характеристиками сети необходим доступ к большому количеству сетевой информации. При этом особенно важна проблема
обеспечения степени воздействия на управляемую сеть. Как правило, желательно, чтобы каждое отдельно взятое воздействие было минимальным.
Ключевые требования для данного вида управления – способность преобразования первичной информации о сетевой ситуации в формальные показатели (с учётом пороговых значений этих показателей) в соответствующие
периоды времени. К такого рода задачам относится, например, задача преобразования сведений о количестве и продолжительности поступивших вызовов в данные о нагрузке канала связи и последующего вывода о наличии
перегрузки.
Даже из такого простейшего примера следует, что при управлении
производительностью необходима процедура периодического агрегирования (обобщения) информации об эффективности работы сети для выявления тенденций развития сетевой ситуации и планирования пропускной способности. Соответственно, необходимы средства планирования для регулярного сбора информации о работе сети, а также возможность определения времени получения отклика о состоянии объектов управления на сети.
Для данной функциональной области существуют следующие SMF:
сообщения о событиях согласно Рек. МСЭ-Т X.734, регистрация сообщений
согласно Рек. МСЭ-Т X.735, метрический контроль (metric monitoring) согласно Рек. МСЭ-Т X.739, объединение информации (summarisation) согласно Рек. МСЭ-Т X.738, планирование с помощью составления расписания (scheduling) согласно Рек. МСЭ-Т X.746 и контроль времени ответа на
запрос (response time monitoring) согласно Рек. МСЭ-Т X.748.
46
Управление безопасностью (security management) затрагивает два аспекта защиты систем:
 управление собственно безопасностью (management of security) способность контроля и управления средствами защиты и своевременного сообщения об угрозах безопасности или нарушениях
безопасности сетей и средств связи;
 безопасность управления (security of management) - возможность
опознавания пользователей системы управления и соответствующих прикладных программ, что гарантирует конфиденциальность
и целостность обмена информацией управления и предотвращает
несанкционированный доступ к информации управления. Услуги
установления подлинности, обеспечения целостности данных и
конфиденциальности являются общими для всех прикладных программ ВОС и затрагивают все процедуры управления согласно
Рек. МСЭ-Т X.800.
Ключевые требования при управлении безопасностью согласно модели ВОС – это поддержка аварийных сообщений о безопасности, средства
для проведения аудита безопасности и средства управления доступом. Соответствующие SMF: сообщения о событии согласно Рек. МСЭ-Т X.734, регистрация согласно Рек. МСЭ-Т X.735, аварийные сообщения о безопасности Рек. МСЭ-Т X.736, аудит выполняемого процесса безопасности (security
audit trail) согласно Рек. МСЭ-Т X.737, управление доступом согласно Рек.
МСЭ-Т X.741.
2.5 Контрольные вопросы к разделу 2
1.
2.
3.
4.
5.
6.
7.
8.
Что такое «открытая система»?
Перечислите уровни модели взаимосвязи открытых систем, ВОС.
Что такое «сущность» в рамках модели ВОС?
Какие функциональные области управления выделяют в открытых
системах?
Какие базовые операции управления осуществляются при управлении приложениями?
Какие существуют функциональные состояния объекта в модели
ВОС?
Какие могут быть причины генерации аварийных сообщений?
Что включает область управления рабочими характеристиками и
производительностью?
47
РАЗДЕЛ 3. УПРАВЛЕНИЕ
ТЕЛЕКОММУНИКАЦИОННЫМИ СЕТЯМИ И
СИСТЕМАМИ НА ОСНОВЕ TMN
3.1 Состав и назначение основных элементов TMN
Термин «Сеть управления электросвязью» (Telecommunication Management Network, TMN) введен МСЭ-Т с 1992 г. Общие положения концепции TMN определены в Рек. МСЭ-Т M.3010. Концепция TMN основана на
базовых принципах управления открытыми системами. Согласно Рек.
МСЭТ M.3010, TMN является самостоятельной сетью, «надстройкой» над
традиционной сетью электросвязи. Сеть TMN обеспечивает управление, оперативный контроль (мониторинг) и автоматизированную эксплуатацию телекоммуникационного оборудования (см. рис. 3.1). Сеть TMN используется для
управления услугами сетей связи, для администрирования сетевыми устройствами в целях обеспечения нормативного качества оказания услуг связи и
безопасности связи.
Операционная
система
Операционная
система
Операционная
система
TMN
Сеть передачи данных
К другим
системам
TMN
Абонент А
Рабочая
станция
TMN
D
W
D
M
Узел связи
D
W
D
M
Система
передачи
Система
передачи
Узел связи
Абонент Б
Сеть электросвязи
Рис. 3.1 – TMN и сеть электросвязи (согласно Рек. МСЭ-Т М.3010)
Объектом управления сети TMN являются телекоммуникационные или
сетевые ресурсы. Телекоммуникационные ресурсы управления физически
представляют собой оборудование связи – стативы, функциональные блоки,
48
модули  на определённые свойства которых можно осуществлять целенаправленное управляющее воздействие. Например, можно с помощью изменения станционных данных запрещать организацию обходных направлений
связи через определённый узел, повышать уровень допустимых потерь в
направлении, административно блокировать доступ абонента к услугам связи. При управлении по стандартам TMN оборудование связи обычно называется элементом сети (network element, NE) или сетевым элементом.
Сеть TMN предоставляет оператору связи услуги управления сетями
электросвязи (management service). Услуги управления определяются как
решения, предлагаемые TMN для удовлетворения потребностей оператора в
сетевом управлении. Услуга управления в TMN состоит из множества компонентов, причём самая элементарная из этих компонентов, например генерация сообщения о неисправности (отказе), определяется как функция управления (management function). Сеть TMN предоставляет оператору связи множество функций управления телекоммуникационными сетями и услугами,
обеспечивая обмен информацией в процессе управления. Обмен информацией управления (management information) предусматривает прежде всего выдачу команды управления, выполнение команды, передачу в систему управления результатов выполнения команды.
Обмен командами управления и иной информацией между TMN и оборудованием связи осуществляется через опорные точки, которые реализуются в виде стандартизованных или нестандартизованных МСЭ-Т интерфейсов
TMN.
Для передачи сигналов и команд управления, TMN подключается к
оборудованию электросвязи по сети передачи данных (data communication
network, DCN). Сеть DCN реализует транспортные уровни сети TMN согласно модели взаимосвязи открытых систем. Функции прикладного уровня TMN
реализуются с помощью одной или нескольких операционных или управляющих систем (operations systems, OS).
База
данных
сетевого
управления
Приложение
управления
Приложение
управления
Модель сети
Операционная или управляющая система (OS) TMN
Рис. 3.2 – Операционная система в TMN
В первую очередь, операционные системы (см. рис. 3.2) обеспечивают
поддержку обработки данных, поступающих от управляемой сети электросвязи. Эта обработка осуществляется в целях мониторинга и контроля функ49
ционирования телекоммуникационного оборудования, а также для обеспечения работы собственно сети TMN. Операционная система поддерживает информационную модель сети электросвязи.
Информационная модель сети электросвязи представляет собой логическое описание физических объектов электросвязи с использованием принятой информационной технологии и специальных программных средств,
например систем управления базами данных (СУБД). Операционные системы обеспечивают поддержку прикладных программных средств управления
(приложений управления), которые, собственно, и реализуют большинство
услуг и функций управления системами. Функции управления могут выполняться непосредственно человеком-оператором или осуществляться в автоматическом режиме. Кроме того, OS обеспечивает поддержку терминалов
пользователя, форматирование данных.
Выполнение некоторых функций управления может обеспечиваться
несколькими операционными системами. В этом случае сеть передачи DCN
используется для обмена информацией между различными управляющими
системами. Другими словами, с помощью DCN данная система сетевого
управления может взаимодействовать с другими TMN.
Сеть DCN также используется для соединения между рабочими станциями (work stations, WS) и операционными системами, что позволяет операторам и администраторам получать и интерпретировать информацию по
управлению с помощью человеко-машинных интерфейсов. Как правило, рабочие станции имеют графические человеко-машинные интерфейсы, чьи характеристики соответствуют требованиям рекомендаций МСЭТ Z.300; детальное определение такого интерфейса находится вне рамок рекомендаций
МСЭТ по TMN. Рабочая станция поддерживает язык общения «человекмашина» и обладает возможностями обработки данных, средствами ручного
и автоматического ввода-вывода информации.
Основные положения концепции TMN стали результатом длительного
исследовательского процесса. Исследования по TMN были начаты в 1985 году IV исследовательской группой МККТТ (ныне – МСЭ-Т). Первая рекомендация TMN имела код M.30 и была издана в 1988. В 1992 году появилась
полностью пересмотренная версия данной рекомендации, и её номер был изменен на M.3010. Эта версия вновь претерпела изменения в 19962000 году.
Большое количество рекомендаций TMN было разработано МСЭ-Т для
управления сетями ЦСИС (ISDN).
Европейский институт по стандартизации телекоммуникаций (European Telecommunication Standards Institute, ETSI) в свою очередь разработал ряд
спецификаций отдельных элементов TMN, в частности интерфейса Q.3 для
управления первичными сетями синхронной цифровой иерархии SDH.
50
3.2 Функциональные возможности и архитектура TMN
Под функций управления TMN понимается логический элемент, который обеспечивает реализацию задачи управления в любой её части. Совокупность функций управления образует услуги управления. Доступ к услугам управления на уровне функций, а также взаимодействие различных
функций между собой осуществляется через интерфейсы управления. Базовые функции управления TMN описаны в рекомендации МСЭТ M.3200
[20]. В последующих рекомендациях серии МСЭТ M.32xx для некоторых
видов и служб связи описаны индивидуальные услуги управления. Услуги
управления TMN могут быть детализированы с точностью до элементарной
функции. Базовое множество функций TMN, соответствующее функциональным областям управления для семиуровневой модели ISO, описано в
рекомендации МСЭТ M.3400 [30].
Функция управления отражает заключительный этап в определении
требований к сетевому управлению. Выбор существующей или разработка
новой функции управления обусловлены необходимостью реализовать те или
иные задачи управления. Функции управления реализуются в рамках информационной модели управления и допускают многократное использование в
различных услугах управления.
Перечень услуг управления TMN содержится в Рек. МСЭТ M.3020.
Рекомендация M.3200 предусматривает для описания услуги управления т.н.
шаблон. Согласно данному шаблону каждая услуга управления и должна
быть описана в общем виде по нижеследующей схеме (см. таблицу 3.1 на основании Рек. МСЭ-Т М.3200, 1997 г.) :
51
Таблица 3.1 – Услуги и области управления
Сети для
управл-
ОКС
№7
IP
ПСС TMN
СП
Д
ТФО
П
СПС
ИСС
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
ния
Услуга
управления
Администрирование данными
пользователей
Управление тарифами.
Администрирование качеством
услуг связи и
рабочими характеристиками сети
Измерение
нагрузки и анализ результатов
измерения
Администрирование маршрутизацией и системой нумерации
Техническая
эксплуатация и
управление неисправностями
(последствиями
отказов)
Управление
безопасностью
+
+
+
+
Примечание : символ «+» означает, что область управления нуждается в данной услуге
управления.
52
Например, в Рек. МСЭТ M.3200 содержится услуга управления «Техническая эксплуатация и управление неисправностями (последствиями отказов)». Эта услуга требуется для всех видов сетей связи. Управление техэксплуатацией и управление неисправностями обеспечивается группами функций управления: «Наблюдение за неисправностями (отказами)», «Тестирование», «Администрирование в условиях аварийной ситуации».
Группа функций управления «Наблюдение за неисправностями (отказами)» в свою очередь включает в себя множество функций «Сообщение о
неисправности», «Обобщение данных о неисправности» (alarm summary),
«Критерий выбора состояния неисправности» (alarm event criteria), контроль
журналирования сообщения о неисправностях, корреляция и фильтрация
аварийных сообщений. Группа функций «Сообщения о неисправности»
включает в себя такие функции TMN как «Сообщение о неисправности»,
«Маршрутизация сообщения о неисправности» (route аlarm report), «Запрос
истории повреждения» (request alarm history).
В итоге, создаётся следующая иерархия услуг и функций управления
(верхний уровень  1, нижний уровень  4):
1. услуга управления  «Управление техническим обслуживанием»;
2. группа функций управления  «Наблюдение за неисправностями;
3. множество функций управления  «Сообщения о неисправности»;
4. функция управления  «Маршрутизация сообщения о неисправности».
Сеть TMN обладает следующими функциональными возможностями [26,28] :
 способность производить обмен информацией управления
между сетями связи и TMN;
 способность преобразовывать информацию управления для различных систем связи в единый формат с целью обеспечения
совместимости и согласованности данных в сети TMN;
 способность передавать информацию управления между различными компонентами сети TMN;
 способность анализировать и предсказуемо реагировать на информацию управления;
 способность преобразовывать информацию управления в форму, которая понятна пользователю системы управления – оператору или администратору. Это достигается с помощью дружественного взаимодействия с пользователями посредством графического отображения информации;
 возможность обеспечения защищённого доступа к информации
управления.
С учётом сложности и многообразия задач, решаемых сетью TMN, существует несколько способов описания свойств сети TMN. Каждый способ
описания соответствует определённым свойствам сети. В терминах TMN это
53
соответствует описанию архитектуры сети TMN. Под архитектурой понимается совокупное обозначение состава и структуры сети TMN, описание взаимного расположения компонентов сети TMN, определение способов взаимодействия компонентов TMN между собой и с внешней средой. Рекомендация МСЭТ M.3010 определяет общие понятия концепции управления
TMN и представляет несколько видов архитектуры управления для различных уровней описания :
 функциональная архитектура TMN, которая описывает функции
управления;
 физическая архитектура TMN, которая определяет технические и
программные средства реализации функций управления;
 информационная архитектура TMN, которая описывает понятия
TMN на основе стандартов управления ISO в рамках объектноориентированного подхода;
 логическая многоуровневая архитектура TMN (logical layered
architecture, LLA), которая показывает как управление сетью может
быть структурировано в соответствии с различными потребностями
администрации связи.
Перечисленные архитектуры далее рассматриваются более подробно.
Функциональная архитектура TMN состоит из следующих основных
компонентов :
Функциональные блоки (functional blocks) или блоки функций  элементарная единица функциональности TMN, которая может быть стандартизирована.
 Функции приложений управления (management application functions, MAF) - функции, с помощью которых предоставляются одна
или несколько услуг управления. Функции MAF могут обозначаться с помощью тех функциональных блоков, в рамках которых они
применяются. Как правило, в одном функциональном блоке реализуется одна функция MAF. Функции MAF являются основой для
формирования услуг управления.
 Функция управления TMN (TMN management function, TMN MF) и
множество функций управления TMN (TMN management function
sets). Функция TMN MF обеспечивает взаимодействие между парами MAF в управляющей и управляемой системах. Функции TMN
MF группируются в набор функций управления и обеспечивают
взаимодействие c другой функцией MAF.
 Опорные или эталонные точки (reference point) представляют собой описание требований к интерфейсам TMN. Опорные точки не
определяют протокол информационного обмена, но отражают суть
взаимодействия между функциональными блоками; опорная точка
позволяет определить все возможные функции, которые данный
функциональный блок запрашивает у других блоков. В этом смысле
54
опорная точка служит своего рода «логическим разграничителем»
функциональных блоков.
Функциональные блоки являются описанием функций TMN, а именно:
 функции сети передачи данных;
 функции рабочей станции;
 функции интерфейса «человек-машина»;
 функции базы данных управления;
 функции безопасности сети TMN;
 функции обмена сообщениями.
В функциональной архитектуре TMN определено четыре типа функциональных блоков. Нет необходимости, чтобы все 4 типа присутствовали в
каждой возможной реализации TMN.
g
g
WSF
WSF
f
f
q
q
OSF
q
TMN i
OSF
f
x
TMN j
q
OSF
q
q
q
q
NEF
NEF
TF
m
Рис. 3.3 – Опорные точки и функциональные блоки TMN
Существуют следующие типы функциональных блоков (см. рис. 3.3) :
 Функциональный блок управляющей системы (operations systems
function block, OSF).
 Функциональный блок элемента сети (network element function
block, NEF).
 Функциональный блок рабочей станции (workstation function
block, WSF).
 Функциональный блок преобразования (transformation function
block, TF).
Блоки, которые полностью находятся внутри области, помеченной как
«TMN» означает, что эти функциональные блоки полностью описаны в рекомендациях TMN. Оставшиеся функциональные блоки (WSF, NEF и TF)
55
указаны на граничной линии. Это указывает на то, что только часть этих
функциональных блоков описана в рекомендациях TMN. Аналогично, три
класса опорных точек (q, f и x) полностью описаны в рекомендациях TMN;
другие классы (g и m) располагаются вне систем TMN и описаны рекомендациями МСЭТ лишь частично.
Функциональный блок элемента сети, NEF. Как уже говорилось, в
терминах TMN управляемое оборудование обозначается как элементы сети
(network element, NE). Функция NEF описывает функции оборудования электросвязи, доступные для управления TMN. NEF поддерживает обмен информацией с TMN для обеспечения передачи управляющих команд и информации управления. Эта часть NEF, доступная TMN, изображена на рис. 2.3
внутри границ TMN.
Функциональный блок управляющей системы, OSF инициализирует операции управления и получают сообщения/уведомления о выполнении
операций управления. OSF устанавливает связь и взаимодействует с NEF через опорную точку q (см. Рек. МСЭТ M.3010). Рисунок 2.4 показывает отношение между OSF, NEF и q. Услуги, предоставляемые в опорной точке q в
основном относятся к услугам протокола CMIP (см. главу 4).
Граница между
функциональными
блоками
OSF
NEF
Опорная точка q
Рис. 3.4 – Взаимосвязь между OSF, NEF и опорной точкой q
Как видно из рис. 3.4, на отдельно взятой сети TMN (эксплуатируемой
одной администрацией связи) обмен между несколькими OSF осуществляется через опорную точку q. Обмен между OSF в различных сетях TMN (эксплуатируемых различными администрациями связи) осуществляется через
опорную точку x.
Функциональный блок рабочей станции, WSF обеспечивает представление информации управления для пользователя в наиболее доступной и
ясной форме. Функция WSF включает поддержку интерфейса пользователю
через опорную точку g. Этот аспект WSF не являются частью стандартов
TMN. Поэтому на рисунке 2.3 WSF расположена на краю оболочки TMN, а
опорная точка g расположена вне рамок TMN.
Функциональный блок преобразования, TF используется для организации связи между двумя элементами, которые имеют несовместимый механизм информационного обмена. Несовместимыми могут оказаться информационные модели, протоколы обмена. Функции TF могут использоваться
как для связи функциональных блоков внутри сети TMN, так и для организа56
ции взаимодействия с внешними системами. В частности, на границе TMN,
функциональный блок TF обеспечивает взаимодействие с окружением, которое не соответствует стандартам TMN, с помощью опорной точки m. Функция TF преобразовывает информацию на участке от опорных точек q (которые являются стандартными опорными точками TMN) до опорных точек m.
Так как опорная точка m не является целиком стандартной с точки зрения
TMN, то часть функции TF показана на краю оболочки TMN. Кроме того, TF
осуществляет хранение и фильтрацию информации по управлению; преобразование информации из некоторой локальной или частной формы в стандартизированную форму. Взаимосвязь между функциональными блоками и
опорными точками приведены в таблице 3.1 :
Таблица 3.1 – Функциональные блоки и опорные точки TMN
NEF
NEF
OSF
TF
WSF
Не TMN
q
q
OSF
q
q, x1
q
f
TF
q
q
q
f
m
WSF
f
f
Не TMN
m
g
g
Примечания.
1
x интерфейс применяется когда OSF находятся в разных функциональных блоках
Опорная точка g находится между WSF и персоналом, управляющим
сетью.
Функциональный блок в заголовке столбца таблицы 2.1 может обмениваться информацией управления с функциональным блоком в крайней левой
графе через опорную точку, которая указана на пересечении столбца и строки. В случае, если пересечение пусто, функциональные блоки не могут обмениваться информацией управления.
Кроме перечисленных элементов, до 2000 г. описание функциональной
архитектуры TMN включало некоторые дополнительные функции. В частности, это была функция передачи данных TMN (data communication function,
DCF). Несмотря на то, что описание указанных функций исключено из текущей версии рекомендации M.3010, на практике функции передачи данных
DCF, реализованные сейчас в DCN, обеспечивается уровнями с 1 по 3
(транспортные уровни) TMN согласно семиуровневой модели ВОС.
После функциональной архитектуры определим физическую архитектуру TMN.
В физической архитектуре TMN функциональные блоки реализовываются с помощью физических блоков (phisical blocks).
57
Физическим блокам соответствует оборудование связи, ЭВМ, системное или прикладное программное обеспечение. Физическая архитектура
TMN состоит из следующих физических блоков:
 Элемент сети (или сетевой элемент), NE.
 Устройство медиатора (Mediation Device, MD).
 Q-Адаптер (QA).
 Операционная система, OS.
 Рабочая станция, WS.
 Сеть передачи данных, DCN.
Физические блоки являются реализацией одноименных функциональных блоков. К примеру, блок «Элементы сети» выполняет функции элемента
сети т.е. оборудования связи. Функции преобразования TF в данном случае
разделяются на две составляющие: функции адаптации, которую реализуют
устройства адаптации и функции медиации, которую выполняют устройства
медиатора. Физическая архитектура TMN представлена на рис. 3.5.
TMN
Операционная система
OS
К другой
OS
X/F/Q
X
G
F
Сеть передачи данных
DCN
Q
Q
Q
Q
Q-медиатор
Q-адаптер Элемент сети NE
со стандартным
соединением с TMN
Рабочая
станция
WS
Элемент сети NE
с нестандратным
соединеним с TMN
Интерфейс
Рис. 3.5 – Физическая архитектура TMN
Как уже отмечалось, интерфейсы TMN реализуют соответствующие
опорные точки. Рассмотрим далее элементы физической архитектуры.
Функция адаптации и устройство адаптации (adaptation device, AD),
реализующее данную функцию, обеспечивает информационный обмен между физическими элементами, не поддерживающими стандарты TMN и элементами сети (операционной системой), которые соответствуют принципам
TMN. В этом случае, как видно на рис. 3.5. применяется устройство, которое
называется Q-адаптером (Q-adapter, QA). Q-адаптер обеспечивает подклю58
чение элемента сети с несовместимым с 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-медиатор поддерживает
соединения внутри TMN, а X-медиатор поддерживает соединения между
операционными системами различных сетей TMN. Адаптеры и медиаторы
могут выполнять преобразование форматов данных.
Существует техническая возможность реализовать в виде единого физического блока несколько функциональных блоков одного или различных
типов. Например, операционная система может быть использована для выполнения нескольких OSF, а также может применяться для реализации OSF,
MF и WSF. В случае, если физический блок реализует несколько функциональных блоков различных типов, выбор наименования блока определяется
его преобладающим использованием.
В рамках концепции TMN признается, что существует определенная
иерархия «обязанностей», связанных с управлением теми или иными объектами. Такая иерархия может быть описана с помощью термина «уровень
управления»; соответственно архитектура которая описывается с мощью
уровней называется логической многоуровневой архитектурой (logical
layered architecture, LLA) TMN.
Концепция уровней управления стала наиболее важным и наиболее
упоминаемым видом архитектуры TMN. Впервые описание этого вида архитектуры появилось в 1992, как приложение к Рек. МСЭ-Т M.3010. Далее описание данной архитектуры перешло в основной текст рекомендации версии
1996 года и сохранилось в версии 2000 г.
Появление LLA обусловлено тем, что задачи сетевого управления достаточно сложны и многоплановы. Для упрощения управления и разграничения полномочий между различными участниками процесса управления,
функциональные возможности TMN вместе с необходимой информацией декомпозированы (разбиты) на ряд логических уровней.
Общий принцип такого иерархического разбиения показан на рис. 3.6.
59
Уровень 1
Менеджер
SAP
Агент
Менеджер
Уровень 2
SAP
Агент
Уровень 3
Рис. 3.6 – Декомпозиция функциональности управления
Уровень 2 на границе между уровнем 1 и 2 предоставляет услуги по
управлению уровню 1 через опорную точку доступа к услугам (service access
point, SAP). Предоставление услуг реализовано с помощью передачи на вышестоящий уровень 1 информации по управлению, которая формируется с
помощью программы-агента уровня 2. Управление, которое осуществляется
на уровне 1 не требует детальной и подробной информации о состоянии
уровня 2; программаагент на уровне 2 будет обеспечивать только ту информацию по управлению, которая является жизненно необходимой для принятия решений на уровне 1. Здесь действует принцип «знать только то, что
нужно для работы».
Описанный принцип иерархического представления может применяться рекурсивным способом  предоставление информации по управлению
уровнем 3 может быть обеспечено для уровня 2 с помощью программыагента уровня 3. Важно отметить, что по аналогии с моделью ВОС, уровень 1 не может напрямую управлять уровнем 3; для этого уровень 1 получает услуги управления от уровня 2, а уровень 2 в свою очередь получает услуги управления от уровня 3. Другими словами, уровень 1 управляет уровнем 3
только через уровень 2. Применительно к TMN, логическая декомпозиция
уровней управления может быть выражена c помощью следующего разбиения с учётом функциональности :
 Уровень элемента сети (network element layer, NEL);
 Уровень управления элементом (element management layer, EML);
 Уровень управления сетью (network management layer, NML);
 Уровень управления услугами (service management layer, SML);
 Уровень управления бизнесом (business management layer, BML).
Эти уровни, включая их функциональные блоки и опорные точки, показаны на рис. 3.7 на следующей странице.
Данная реализация TMN может включать бизнес-функции операционной системы (business operation system function, B-OSF), которые имеют от60
ношение ко всем управляемым сетям/системам связи и осуществляют общую координацию управления бизнесом оператора связи.
Функции операционной системы по управлению услугами (service operation system function, S-OSF) имеют отношение к услугам связи, предоставляемыми с помощью технических средств одной или нескольких сетей электросвязи. Сервисные S-OSF на уровне управления услугами обеспечивают
интерфейс с абонентом или клиентом.
Функции операционной системы по управления сетями (network operation system function, N-OSF) охватывают различные реализации функции
управления сетями связи. При этом сетевые N-OSF взаимодействуют с OSF
элементов сети E-OSF.
Функции операционной системы по управления элементами сети (element operation system function, E-OSF) обеспечивают управление отдельными элементами сети. Сетевые N-OSF и E-OSF элементов сети обеспечивают
управление сетью электросвязи на уровне телекоммуникационного оборудования и предоставляют информацию о сети по запросам сервисных S-OSF.
Функции элемента сети (network element function, NEF) входят в состав
уровня EML и управляются со стороны уровня элемента сети.
Логическая
многоуровневая
архитектура
Уровень
управления
бизнесом, BML
Функциональная
архитектура
Физическая
архитектура
Система
управления
бизнесом, BMS
Business
OSF
B-OSF
q
Уровень
управления
услугами, SML
Service
OSF
S-OSF
x
Система
управления
услугами, SMS
q
Уровень
управления
сетью, NML
Network
OSF
N-OSF
x
Система
управления
сетью, NMS
q
Уровень
управления
элементом, EML
Element
OSF
E-OSF
x
Система
управления
элементами,
EMS
q
Уровень
элемента
сети, NEL
Network
Element
NEF
x
Рис. 3.7 – Логическая многоуровневая архитектура TMN и её связь с
61
другими архитектурами
В рамках LLA предполагается, что программы-менеджеры OSF любого
уровня могут управлять OSF-агентами, находящимися на том же уровне, либо на нижнем уровне. Это управление, как в пределах данной сети TMN так и
между разными сетями TMN, осуществляется через опорные точки q или х
соответственно. Управление агентами NEF осуществляется с помощью EOSF.
Уровень элемента сети (network element layer, NEL). Уровень элемента сети – это телекоммуникационное оборудование с функционирующей
программой-агентом для сбора информации и обработки управляющих воздействий, поступающих от уровня управления элементом.
Уровень управления элементом сети (element manager layer, EML).
Индивидуальные элементы сети управляются с помощью функций E-OSF на
уровне управления элементом. На этом уровне осуществляется взаимодействие со специфическими функциями данного оборудования, реализация которых зависит от поставщика оборудования. В результате специфические
функции оборудования «скрываются» от других уровней LLA уровнем
управления элементом. В качестве примера можно привести следующие
функции, выполняемые на уровне управления элементом сети:
 обнаружение ошибок и неисправностей телекоммуникационного
оборудования и систем связи;
 измерение мощности, потребляемой оборудованием;
 измерение задействованных ресурсов оборудования связи, например загрузка центрального процессора, наличие свободного места в
буфере передачи/приема, длина очереди и т.п;
 регистрация статистических данных.
Следует отметить, что OSF (на уровне управления элементом) и NEF
могут быть выполнены
в виде единого или различных аппаратнопрограммных модулей.
Уровень управления сетью (Network Management Layer). Уровень
управления сетью осуществляет функции управления, касающиеся взаимодействия между многими видами телекоммуникационного оборудования. На
уровне управления сетью внутренняя структура элемента сети «невидима»,
это означает, к примеру что состояние буфера устройства приема/передачи,
температура оборудования и т.п. не могут напрямую контролироваться и
управляться этим уровнем. С другой стороны, здесь доступны сведения о состоянии внешних портов, соединительных линий, загрузке процессоров элементов сети.
Примеры функций, выполняемых на уровне управления сетью:
 создание полного представления о сети (информационная модель
сети);
 поддержка QoS для конечных пользователей;
 модификация и обновление таблиц маршрутизации;
 мониторинг загрузки линий и каналов связи;
62
 динамическое управление трафиком;
 обнаружение неисправностей и ошибок программного обеспечения.
Функции OSF на уровне управления сетью используют информацию
по управлению, которая не зависит от производителей систем. Эта информация предоставляется с уровня управления элементом сети.
Уровень управления услугами связи (service management layer,
SML). Уровень управления услугами (сервисами) затрагивает вопросы
управления, которые непосредственно касаются потребительской ценности
услуг электросвязи. Пользователями данного уровня могут быть клиенты
оператора, абоненты сетей связи, а также администрации операторов связи
или провайдеры услуг. Управление услугами осуществляется на основе информации, которая обеспечивается уровнем управления сетью; при этом уровень управления услугами «не видит» детальную внутреннюю структуру сети. Это весьма полезное свойство с учётом обеспечения информационной
безопасности и коммерческой тайны оператора связи. Маршрутизаторы IPсетей, традиционные АТС, системы передачи, базовые станции и центры
коммутации систем подвижной связи не могут непосредственно управляться
с уровня управления услугами.
Примеры функций управления, которые выполняются на уровне
управления услугами:
 контроль качества услуг связи (задержки, потери, и т.д.);
 учет объема использования услуг связи;
 тарификация (расчёты) за услуги связи;
 назначение сетевых адресов и номеров телефонных аппаратов;
 сопровождение группы адресов или номеров, например номеров
присоединенного оператора.
Управление услугами может осуществляться различными способами.
Первый случай - два оператора обмениваются информацией по управлению
для того, чтобы управлять своими взаимосвязанными сетями (межоператорское управление). Из соображений безопасности и с учётом конкуренции на
рынке связи каждый из этих операторов будет скрывать внутреннюю структуру своей сети связи от другого оператора. Обмен будет осуществляться
только в той части информации управления, которая является жизненно необходимой для обеспечения качества предоставления услуг связи. К примеру, это могут быть данные о приоритетах абонента, профиль услуг абонента,
данные об интенсивности принимаемой-передаваемой нагрузки.
Второй случай – оператор сети связи обменивается информацией по
управлению с системой управления, которая принадлежит одному из клиентов оператора или присоединенному оператору связи. Основной оператор
вновь скрывает внутреннюю структуру сети от клиента и обеспечивает доступ только к общей информации о количестве и качестве предоставленных
услуг, например о количестве и продолжительности телефонных разговоров.
Уровень управления бизнесом (business management layer, BML).
Уровень управления бизнесом отвечает за управлением предприятием связи
63
или компанией связи. Этот уровень управления следует рассматривать в самом широком контексте, при этом управление сетью и услугами связи 
только часть управления бизнесом. Управление бизнесом непосредственно
связано со стратегией управления сетями электросвязи в экономическом аспекте и не затрагивает оперативнотехническое управление сетью электросвязи.
На основании логической многоуровневой архитектуры TMN можно
осуществлять логическое разбиение систем управления (management system,
MS). Физически MS представляют собой распределенную или централизованную вычислительную систему, которая состоит из серверных ЭВМ, специализированных устройств-адаптеров или медиаторов и персональных компьютеров, которые связаны между собой с помощью сети передачи данных
DCN.
На серверах и компьютерах пользователей установлено разнообразное
программное обеспечение (ПО): операционные системы, ПО удаленного доступа, системы управления базами данных (СУБД), управляющие системы
OS, приложения управления электросвязью и средства администрирования
этими приложениями.
Как правило, системы управления рассматриваются в рамках физической архитектуры TMN. Это позволяет упростить схемы функциональных
архитектур. Для описания принадлежности систем управления к уровням
LLA применяются следующие обозначения:
 Система управления бизнесом (business management system, BMS)
 Cистема управления услугами (service management system, SMS)
 Система управления сетью (network management system, NMS)
Cистема управления элементами сети (element management system, EMS)
Администрации связи пользуются услугами управления сетями связи с
помощью специальных программных приложений, которые поддерживаются
OS. Эти приложения могут осуществлять аналитическую обработку данных и
взаимодействовать с пользователями. Например, пользователь может вывести на экран графики ежедневной нагрузки, сведения об отказах оборудования, проанализировать качество предоставления услуг связи и т.п. Кроме того, программные приложения управления осуществляют сбор, обработку
данных от оборудования и систем электросвязи, генерацию и передачу
управляющего воздействия (команды) на элемент сети и получение отклика
элемента с результатом операции.
Система управления любого уровня может включать OS как своего, так
и нижележащих уровней. Поставщики систем управления предлагают, как
правило, определенный выбор приложений управления, который приводится
в условиях заказа. Выбор приложений заказчиком может привести к изменению исходного типа системы управления.
64
3.1 Интерфейсы TMN
3.3.1 Общие сведения об интерфейсах TMN
Функции управления доступны через интерфейсы. Для интерфейсов
TMN можно сформулировать следующие общие требования по функциональности :
 Поддержка нескольких одновременно работающих систем управления
т.е. данный объект может управляться различными OS. Управляемый
объект должен генерировать соответствующие уведомления для каждого приложения управления.
 Обеспечение коммуникативности  поддержка операций управления
должна осуществляться как в асинхронном так и в синхронном режиме.
Синхронный режим операций предусматривает, что управляемые объекты предварительно проверяются на предмет осуществления той или
иной операции. Если хотя бы один объект не может выполнить операцию, то она не осуществляется.
 Подтверждения о результатах операции  интерфейс должен обеспечить передачу положительных или отрицательных подтверждений о
завершении операции.
Требования к интерфейсам TMN затрагивают в том числе и требования
к проектированию, построению, к проверке системы управления на соответствие стандартам TMN. Основной целью проверки системы управления является оценка степени взаимодействия различных элементов систем сетевого
управления через используемые интерфейсы. Взаимодействие элементов
должно обеспечить единство системы управления в той мере, в какой это
требуется для оператора связи и для реализации функций управления. Детально проформа (методика) проверки интерфейсов на соответствие требованиям TMN описана в Рек. МСЭТ Q.823.1 «Management Conformance Statement Proforma», 1997 (Проформа утверждения о соответствии управлению).
Далее рассмотрим основные интерфейсы TMN, с помощью которых осуществляется взаимодействие между функциями управления, функциональными блоками и осуществляется доступ пользователей к услугам управления.
Интерфейсы могут рассматриваться как физическая реализации опорных точек TMN. В то время как опорные точки можно сравнить с услугами
управления, интерфейсы можно сравнить со шлюзами, с помощью которых
услуги становятся доступны пользователю. Через интерфейсы реализуется
взаимодействие между различными элементами (физическими блоками)
TMN или взаимодействие сети TMN и внешнего окружения. С точки зрения
модели ВОС, интерфейсы обеспечивают интероперабельность т.е. позволяют сохранять взаимосвязь между различными открытыми системами или
между уровнями открытых систем. Для сетей TMN это означает взаимодей65
ствие между физическими блоками безотносительно к типу устройств и производителю оборудования связи. При этом стандартный интерфейс TMN получает то же самое имя (но записывается заглавными буквами!), что и соответствующая опорная точка.
Взаимосвязь опорных точек и соответствующих им интерфейсов выглядит следующим образом :
Опорная точка
Интерфейс
q
Q
x
X
f
F
Спецификации интерфейсов TMN осуществляются различными организациями, в том числе МСЭ-Т, ETSI, TMF. Спецификации интерфейсов, как
правило, содержат формальное описание управляемого объекта с помощью
выбранного метода описания и сценарий использования интерфейса. Иногда
сценарий использования интерфейса TMN не входит в состав рекомендаций
TMN. В спецификациях интерфейсов TMN указываются все ресурсы, доступные для управления и способы доступа к информации управления. Спецификация интерфейса TMN определяет функциональность интерфейса; в
спецификации не содержится описание протоколов, которые используются
для обмена информацией через интерфейс. Методология, которую нужно
применять при проектировании и разработке интерфейсов TMN, описана в
Рек. МСЭ-Т M.3020.
Согласно этой методологии, проектирование интерфейса TMN начинается с определения услуги управления, доступ к которой желательно получить с помощью интерфейса. Далее услуги управления декомпозируются
(разбиваются) на отдельные компоненты; компоненты услуг управления, в
свою очередь, декомпозируются на функции управления. Функции управления описываются с помощью объектно-ориентированного подхода в виде
классов объектов управления. При этом возможно использование средств
моделирования, например UML.
После моделирования осуществляется фаза консолидации и объединения разработанных классов объектов в единую информационную модель интерфейса. На этапе консолидации подтверждается, что первоначально спланированные услуги управления поддерживаются классом объектов управления, который создан разработчиком. На всех этапах разработки безусловно
учитываются содержание процесса управления, правила управления и цели
управления.
Услуги управления и функции, необходимые для разработки информационной модели управления документированы в Рек. МСЭ-Т M.3200 и
M.3400. Эти рекомендации в большей степени носят информативный чем
нормативный характер. Поскольку интерфейсы TMN созданы на базе объектно-ориентированного подхода, новые разработки интерфейсов должны
66
учитывать основную сетевую информационную модель согласно Рек. МСЭ-Т
M.3100 (см. Приложение).
Существует три стандартных интерфейса TMN : интерфейс Q, интерфейс F и интерфейс X.
Интерфейс Q указывает, какая часть информации об объекте управления совместно используется и операционной системой и элементом сети.
Другими словами, интерфейс Q определяет, какие телекоммуникационные
ресурсы и операции элемента сети будут «видны» сети TMN в процессе
управления, а какие ресурсы «не видны». Тот же интерфейс Q применяется
на стыке OS – NE и на стыке OS – OS.
Интерфейс F позволяет соединить рабочую станцию WS и физические
блоки TMN, которые поддерживают реализацию OSF и TF. Соединение осуществляется через сеть передачи данных DCN.
Интерфейс X поддерживает взаимосвязь TMN и других внешних систем, включая другие сети TMN. Интерфейс X используется для управления
оказанием коммерческих услуг. Это возможно при наличии в корреспондирующих системах интерфейсов, взаимодействующих с TMN. C учётом факта
передачи информации во внешнее окружение, уровень информационной безопасности для интерфейса X должен быть выше, чем для интерфейса Q. По
аналогии c интерфейсом Q, интерфейс X определяет для внешних систем видимую часть «айсберга» сети TMN и порядок доступа к ресурсам сети TMN.
3.3.2 Описание интерфейса Q
Интерфейс Q (ранее интерфейс Q.3) является стандартным интерфейсом управления между элементом сети (адаптером, медиатором) и OS. Интерфейс Q включает все уровни модели взаимосвязи открытых систем с использованием отдельных протоколов на каждом уровне реализации.
Общий вид стека протоколов модели ВОС, используемых при реализации интерфейса Q представлен на рис. 3.8.
Подробно реализация транспортного уровня интерфейса Q представлена в Рек. МСЭТ Q.811, реализация верхних уровней интерфейса Q в рамках
модели ВОС представлена в Рек. МСЭТ Q.812. Дополнительно в рекомендации МСЭТ G.784 представлено описание интерфейса Q для управления
сетью первичной цифровой иерархии SDH.
Прикладной уровень управления (уровень приложений) предлагает две
услуги: услуги CMISE для управления и услуги протокола FTAM для передачи файлов с целью загрузки программного обеспечения. FTAM использует
услуги ASCE, в то время как CMISE использует услуги как ACSE так и
ROSE. Уровень представления в стеке интерфейса Q обеспечивает кодирова
ние данных в обусловленном формате.
67
Прикладной уровень управления
(приложения управления)
Специфические
ASE управления
FTAM
Стандарт
ISO 8571
CMIP cтандарты ISO 9595, 9596
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
Транспортный уровень Рек. МСЭ-Т X.224 X.214
ISO 8473-3 (CLNS)
ISO 8208 X.25
уровень пакета
ISO 8473-3
(CLNS)
ISO 7776 LAPB
X.25 уровень
звена данных
ISO 802.3 LCC
ISO 802.3 MAC
Q.921 LapD
X.21 / X.21 bis
V.35 G.703
ISO 802.2
Ethernet
SDH DCC
2M TS n
ISO 8473-4
(CLNS)
CLNP/CONP
AAL5
Сетевой
уровень
ATM
Канальный
уровень
Физическая
сеть
Физический
уровень
Рис. 3.8 – Реализация интерфейса Q
Сессионный уровень обеспечивает управление сессией, т.е. открытие и
закрытие процесса обмена информацией между взаимодействующими приложениями. В случае потери соединения между приложениями, сессионный
уровень пытается это соединение восстановить. Если соединение прерывается на долгое время, сессионный уровень может завершить данное соединение
и создать новое. Эти действия прозрачны для уровня представления и прикладного уровня. Сессионный уровень в стеке интерфейса Q обеспечивает
пункты синхронизации в потоке передаваемых и принимаемых блоков данных (пакетов).
Транспортный уровень обеспечивает оконечные соединения. Имеется
несколько протоколов транспортного уровня. Транспортный уровень осуществляет контроль потока данных т.е. информация передаётся только в том
случае, когда адресат позволяет передачу источнику сообщения. Это предупреждает ситуацию, при которой информация посылается быстрее, чем она
может быть обработана получателем. Транспортный уровень осуществляет
выявление ошибок и их коррекцию в пакетах данных, например в случае если данные были повреждены при передаче или переприёме. Если поле данных в протокольном блоке слишком велико, то транспортный уровень осу68
ществляет разбиение на блоки (пакеты) меньшей длины при передаче и обратную процедуру сборки протокольного блока на приёме.
На физическом, канальном и сетевом уровнях обеспечивается маршрутизация информации управления в DCN, которая передаётся через интерфейс
Q. Передача данных по управлению может осуществляться средствами протокола FTAM на прикладной уровень. Средства интерфейса управления Q
обеспечивают шлюз к программному обеспечению менеджера или агента.
Это программное обеспечение, по сути, выполняет функции интерфейса Q
т.к. поддерживает описание характеристик и режима функционирования
управляемого объекта, обеспечивает доступ к функциям и услугам управления.
Сетевой уровень обеспечивает маршрутизацию пакетов и доставку пакетов данных к любому узлу в сети. Основная часть доставки пакета данных
сводится с передаче пакета от одного узла к другому на основании локальной таблица маршрутизации узла. Эта часть процесса передача определяется
с помощью сетевого протокола передачи без установления соединения (connectionless network protocol, CLNP). Усовершенствование CLNP состоит в автоматическом создании и обновлении локальной таблицы маршрутизации.
Эта часть описывается протоколами обмена между оконечной открытой системой (end system, ES) и промежуточной открытой системой (intermediate system, IS) или протоколом ISIS. Формат пакетов данных, например кодировка адреса и данных определены в протоколе CLNP.
На сетевом уровне данные интерфейса Q, могут передаваться, например, через канальный временной интервал в первичном групповом тракте E1
по принципу «из конца - в конец». Этот способ применяется при организации
управления удалёнными элементами сети.
При расположении управляемых объектов и рабочей станции управления на одном объекте для передачи данных интерфейса Q используется локальная вычислительная сеть.
Канальный уровень обеспечивает определение ошибок и коррекцию
данных на уровне бита. Оконечное соединение организуется с помощью протокола 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 в основном
разрабатываются
с
помощью объектноориентированного подхода различными международными институтами
69
по стандартизации, такими как ETSI, МСЭ-Т, ISO и производственными консорциумами, подобно ATM Форуму (ATM Forum). В частности, ATM Форум
разрабатывает спецификации для интерфейсов управления оборудованием,
использующим асинхронный режим переноса ATM.
Для одного и того же типа телекоммуникационного оборудования с
помощью объектноориентированного подхода может быть разработано несколько информационных моделей интерфейса Q, причём каждая модель затрагивает одну из функциональных областей управления. Это подтверждается анализом многочисленных рекомендаций ETSI и аналогичных рекомендаций МСЭ-Т, которые описывают модель интерфейса Q для управления конфигурацией и неисправностями сетью доступа и портами пользователя на базе интерфейса V.5.1, V.5.2.
По адресу в Интернете www.etsi.org в свободном доступе можно найти
множество спецификаций интерфейса Q для управления различными сетями
и оборудованием связи. С учётом предполагаемого повсеместного перехода к
повременному учёту местных телефонных соединений безусловно актуально
ознакомление с Рек. МСЭ-Т Q.825 «Спецификация приложений управления
на интерфейсе Q.3 : Подробная запись о состоявшемся соединении» (введено
в действие с 06.1998 г.) – см. перечень в Приложении.
Функциональные возможности интерфейса Q определяются тем,
насколько проведённая работа по спецификации интерфейса соответствует
реальным характеристикам и возможностям оборудования.
К примеру, пусть создаётся спецификация интерфейса Q для управления абонентским комплектом. В модели отсутствует описание состояний
абонентского комплекта с атрибутами «комплект административно заблокирован» и «комплект разблокирован» и допустимыми операциями («изменить
состояние комплекта»).
Следовательно, оператор будет лишён возможности заблокировать доступ к услугам связи для злостного неплательщика за услуги связи т.к. отсутствует соответствующий раздел модели, позволяющий реализовать операцию административной блокировки. Технически проблема состоит в том,
что программа-менеджер попросту не «увидит» в программе-агенте и, соответственно, в базе MIB требуемых возможностей по блокировке – ведь их не
описали в информационной модели.
Функциональность интерфейса Q, который применяется для управления АТС [33] может выглядеть следующим образом (см. таблицу 3.2) :
70
Таблица 3.2 – Функции управления, доступные через интерфейс Q
№
Управляемая
№
область
п/п
1
Управление
абонентcкими и
станционными
данными
2
Управление
трафиком
3
Управление
системными
ресурсами
Функции управления
Обеспечение предоставления услуг ТФОП
Обеспечение предоставления услуг IP
Управление услугами VPN/безопасностью/AAA
Тестирование и мониторинг абонентских и соединительных линий
Маршрутизация потоков вызовов
Управление трафиком
Управление сигнализацией
Измерение трафиком
Обеспечение живучести при повреждениях
Обработка событий
Журналирование
Управление абонентским интерфейсом
Сбор данных об использовании оборудования
Управление безопасностью
Управление программным обеспечением
Услуги управления абонентскими данными, которые доступны через
интерфейс Q, включают, например, определение вида информации, которая
доступна абоненту (например, телефония, факсимильная связь или телеконференции), контроль использования дополнительных услуг (переадресация
входящего вызова, конференц-связь, телематические услуги и т.п.).
Модель интерфейса Q для управления телефонной нагрузкой описывает функции управления трафиком, связанные с обработкой вызова в телефонной сети общего пользования ТФОП и ЦСИО. Цель управления телефонной нагрузкой состоит в обеспечении завершения соединением максимально
возможного числа поступивших вызовов при различных условиях эксплуатации узлам коммутации (нормальный режим и перегрузка).
Управление маршрутизацией потоков вызовов связано с функциями
анализа цифр набора номера, для определения источника и адресата, и с
функциями маршрутизации, требуемых, чтобы направить обращение к адресату по прямому или транзитному пути.
В настоящее время большинство спецификаций интерфейса Q основаны на базовых принципах управления, определенных в рекомендации МСЭТ серии X.700 и M.3100.
71
3.3.3 Описание интерфейса X
Для примера возможностей интерфейса X рассмотрим управление
установлением, поддержкой и разъединением тракта между первичной сетью
операторов А и Б через первичную цифровую сеть SDH оператора В на основании данных источников [22,25].
Как известно, сети SDH разделяются на транспортные слои. Слой каналов обеспечивает передачу пользовательской информации из конца в конец;
слой трактов, поддерживает транспорт виртуальных контейнеров (virtual container, VC) и делится на тракты низшего и высшего порядков. Слой секций
гарантирует передачу циклов SDH (STM-n) между сетевыми узлами.
Сеть может быть разбита на подсети которые связываются между собой промежуточными трактами или звеньевыми соединениями.
Иерархическая модель сети SDH в соответствии с европейской схемой
приведена в документе ETSI EN 300 147 V1.4.1. «Transmission and Multiplexing; Synchronous Digital Hierarchy (SDH); Multiplexing structure», 2001. [Передача и мультиплексирование; Синхронная цифровая иерархия; Структура
мультиплексирования]). Общая схема данной модели представлена на рис.
3.9:
Слой каналов
VC-12
VC-2
VC-3
VC-4
Слой трактов
низш его порядка
Слой трактов
высш его порядка
Слой м ультиплексны х секций
Слой секций
Слой регенерационных секций
С лой ф изической среды
Рис. 3.9 – Иерархическая модель структуры сети SDH
На уровне сети управляемыми объектами являются элементы сети
(мультиплексоры или кросс-коннекторы), линии между ними и тракты VC.
Тракты VC соединяются через промежуточные тракты с помощью оконечных элементов первичной сети. В результате создаётся трасса или путь.
Тракты могут создаваться ручным или автоматическим выбором трактов
VC-n на каждом звене пути между требуемыми элементами сети. Основные
72
функции уровня управления сетью SDH связаны с обслуживанием трактов
VC-12, VC-2, VC-3, VC-4 по принципу «из конца в конец». Тракты VC-n образуются на свободных позициях синхронного транспортного модуля STM-n
между двумя оконечными узлами передачи.
Функциональные возможности интерфейса X рассмотрим на примере
двух составляющих процесса управления, а именно управление организацией
трассы или пути (path provisioning) и управление неисправностями (fault
management).
Для описания интерфейса управления X между OS оператора А, OS
оператора Б и OS оператора В предполагается, что в каждой OS есть как
программыменеджеры так и программыагенты, как это показано на рис.
3.10.
OS
оператора
В
Интерфейс X между
операторами А и В
Интерфейс X
между операторами
БиВ
x
x
OS
оператора
А
x
OS
оператора
Б
Интерфейс X
между операторами
АиБ
Рис. 3.10 – Интерфейс X при межоператорском взаимодействии
STM-64
STM-16
S16
S16
STM-64
S64
S64
Техническая сторона задачи выглядит следующим образом. Имеется
сеть SDH условноисходящего оператора А, сеть SDH оператора назначения
Б и транзитная сеть SDH оператора В (см. рис. 3.11).
STM-64
Путь
VC-12
в VC-4
S16
S16
STM-64
STM-16
S64
Оператор А
VC-12 в
VC-4
Оператор В
S64
S16
S64
STM-16
STM-16
Оператор Б
Рис. 3.11 – Организация связи между операторами первичной сети
73
Основной целью межоператорского управления первичной цифровой
сетью SDH в рассматриваемом примере является автоматизация управления
трактом VC12, который мультиплексирован в тракт VC4. Управляемые
ресурсы состоят из соединений трактов (link connections, LC), VC4 и сетей
оператора А, Б и В. При этом точкой пересечения LC и условной границы сети операторов управляет только один из оконечных операторов. Каждый из
операторов А, Б или В может уведомить других операторов о тех сетевых ресурсах, которые он желает сделать доступными для использования третьей
стороной. Cети, где тракт VC12 начинается и заканчивается, называются
шлюзами.
Для рассматриваемого случая не существует центральной базы данных
с информацией по управлению. Каждый оператор имеет собственные сведения о своей сети и сетях, с которыми он взаимодействует c использованием
технологии распределённой базы знаний SMK. Операторы должны распространять данные об изменении характеристик своей сети, прежде всего аварийные сообщения. Аварийное сообщение в первую очередь получает именно тот оператор, который использует неисправный ресурс. Далее рассмотрим
отдельно группу услуг управления предоставлением пути/трассы (path provisioning) и группу услуг управления неисправностями.
Когда оператор А желает задействовать для передачи тракт VC12 через транзитную сеть оператора В, этот тракт VC12 и предоставляемое соединение тракта (deliverablerable link connection, DLC) должны быть предварительно зарезервированы. Соединение тракта VC-12 осуществляется в
слое трактов низшего порядка. Запрос на резервирование посылается условно
исходящим оператором А ко всем операторам вдоль предполагаемого пути.
Получаемые оператором А ответы на запросы содержат идентификаторы
(identificators, ID) оконечных точек пути по каждому оператору и ID зарезервированных DLC. Когда запрос на резервирование удовлетворен, оператор А
может активировать (задействовать) путь, посылая следующие сигналы операторам Б и В :
 запрос на активизацию DLC;
 запрос на установление соединений трактов в сетях между DLC, которые начинаются и заканчиваются известными оконечными точками с идентификатором ID.
Предусмотрена возможность частичного освобождения пути, который
ещё не был задействован. Процедура отмены резервирования запускается
автоматически в том случае, если DLC не был активизирован в течении оговоренного периода времени.
Множество функций управления MFS, которые используются для организации предоставления пути, состоит из следующих функций :
 Резервирование DLC  резервирование множества DLC внутри пути.
 Отмена резервирования DLC  отмена резервирования множества
DLC внутри пути.
74
 Отмена резервирования по истечении времени  отмена резервирования DLC в связи с несостоявшейся активизацией за указанное
время.
 Активизация пути  активизация множества DLC или соединения
подсети SNC (SubNetwork Connections, соединение через подсеть
между окончаниями пути, где подсеть – это часть сети оператора).
Активизация, как правило, осуществляется сразу после резервирования.
 Разъединение пути  деактивизация и отмена резервирования множества DLC или SNC внутри пути
 Обновление доступных соединений  обусловленное внутренними
причинами изменения доступных соединений DLC внутри пути.
 Возможность обновления соединения  уведомление, которое обозначает техническую возможность подсети поддерживать установление новых соединений.
Множество функций управления, как показано ранее в разделе 3.1, декомпозируются на отдельные функции управления. Результат декомпозиции
показан в таблице 3.3. Реализация каждой функции управления из таблицы
3.3 состоит из запроса и уведомления (сообщения в ответ на запрос).
Таблица 3.3 – Функции управления для организации пути в сети SDH
Наименование множества функций управления MFS
Резервирование DLC
Отмена резервирования DLC
Отмена резервирования по истечении времени
Активизация пути
Разъединение пути
Обновление доступных соединений
Возможность обновления соединения
Функции управления
Резервирование DLC (DLC Reservation)
Распространение по сети изменений в данных о
доступных соединениях (Available Connections
Change Dissemination, ACCD).
Отмена резервирования DLC
ACCD.
ACCD.
Активизация DLC
Установка SNC
Разъединение DLC
Разъединение SNC
ACCD
Чтение данных о доступных соединениях
Способность распространять по сети информацию
об изменении соединений, ATCCD (ability to
connect change dissemination)
75
Функции управления
Наименование множества функций управления MFS
Способность к чтению данных о доступных соединениях
Группа услуг управления неисправностями обеспечивает передачу сообщений о неисправностях только операторам, которые используют данные
тракты и подсети. Операторы на рис. 3.11 должны поддерживать журналирование в специальный файл всех аварийных сообщений, которые посылаются
корреспондирующим операторам. Этот файл журналирования должен быть
частично доступен и другим операторам для того, чтобы сохранить возможность отслеживания (трассировки) всех случайно потерянных сообщений о
неисправностях. Наличие и доступность файла журналирования позволяет
оператору А в любое время получить доступ к файлам журналирования другого оператора для ознакомления и проверки. Доступ осуществляется только
в части аварийных сигналов, посланных оператору А (к примеру, те сообщения, которые могли быть посланы или те сообщения, которые были потеряны).
Когда появляется сообщение о неисправности соединений трактов LC
или об изменениях в отношении существующих соединений LC, то менеджеру, который управляет предоставлением пути, посылается специальное межгрупповое сообщение. Менеджер распространяет это сообщение всем операторам для обновления данных о существующей сетевой ситуации.
Множество MFS, которые входят в состав группы управления неисправностями, состоит из следующих функций :
 Обработка сообщения о неисправности (alarm processing)  получение сообщения о неисправности, распространение сообщения о
неисправности по другим получателям и обновление сведений о
состоянии сети;
 Журналирование аварийных событий (alarm event logging)  включает контроль файлов журналирования.
Множество функций управления неисправностями, доступные через
интерфейс X, состоят из отдельных функций управления, как это показано, к
примеру, в таблице 3.4 на следующей странице. Каждая функция управления
из таблицы 3.4 состоит из запроса и уведомления (сообщения в ответ на запрос).
Таблица 3.4 –– Функции управления для обработки аварийных
сообщений
76
Наименование множества
Функции управления
функций управления
Обработка аварийного сообще- Распространение по сети аварийных сония
общений
Журналирование аварийных со- Проверка файла журналирования
бытий
Итак, на примере первичной сети связи SDH показано, какого рода информацией обмениваются различные операционные системы управления сетью через интерфейс X.
3.4 Описание интерфейсов F и G
Интерфейс F соединяет рабочие станции WS с операционной системой
OS или с устройствами медиации MD. Интерфейс F предназначен для обеспечения доступа пользователя к системе управления электросвязью. Через
интерфейс F происходит обмен данными, которые могут использоваться как
для внутренней обработки в системе сетевого управления, так и для обмена
информации между системами. Здесь могут применяться средства описания
данных GDMO/ASN.1 или IDL. С точки зрения функциональной архитектуры TMN, опорная точка f и соответствующий интерфейс F осуществляют
адаптацию информации OS для функции рабочей станции WSF и рабочей
станции WS. Одновременно опорная точка f может выполнять функцию
транслирования информации OS для дальнейшего представления на дисплее
оператора; разумеется, выполняется и обратная трансляция информации  от
информации, введённой оператором в информацию, понятную OS.
Информационная модель интерфейса F может включать данные, которые недоступны элементу сети, но необходимы для обмена между пользователями системы сетевого управления и OS. К такой информации относятся,
например, списки выполняемых заданий (работ) системы управления, расписание запуска этих работ, информация для поддержки графического интерфейса и т.п. Соответственно на интерфейсе F определены следующие функции управления (см. таблицу 3.5):
77
Таблица 3.5 – Функции управления, доступные через интерфейс F
Управляемая
область
Управление
рабочими
характеристиками
Управление
неисправностями
(последствиями
отказами)
Управление
конфигураций
Управление
расчётами
за услуги связи
Управление
безопасностью
Функции управления
Предоставление информации об измерении трафика
Создание нового графика для обработки сообщений об измерениях трафика
Запрос данных об измерении трафика
Список всех запрошенных сообщений
Отмена запроса об измерении трафика
Генерация аварийного сообщения
Регистрация (журналирование) неисправности
Выбор файла регистрации неисправности
Подтверждение факта неисправности
Испытание оборудования (множество функций)
Планирование испытаний (множество функций)
Получение подробной информации относительно уровня обслуживания абонентов или элементов сети.
Проверка состояния, модернизация, отмена
уровня обслуживания абонентов или элементов
сети.
Конфигурация управляемого ресурса
Получение информации по выставлению счёта
за оказанные услуги связи.
Согласование счёта
Информация пользователя об поступлении
оплаты по счёту
Обеспечение безопасности доступа пользователей в систему управления.
Непосредственный доступ пользователя к функциям, указанным в таблице 3.5 осуществляется через интерфейс G рабочей станции. Интерфейс G
пользователя в TMN можно рассматривать как практическую реализацию
средств интерактивного взаимодействия между системой управления и
внешним агентом. Агентом может являться пользователь системы, физическое устройство, прикладная программа.
Существует несколько стандартов и значительное число рекомендаций,
посвященных описанию интерфейса G. Стандарт ISO 9241 «Эргономические
требования к работе с пультом визуального отображения информации в
учреждении» включает в себя много разделов, посвящённых различным ас78
пектам работы с дисплеями. Только некоторые части этого объёмного документа является международными стандартами. Достоинством этого документа можно считать ориентацию на «человеческий фактор», а не на описание
возможностей программного обеспечения. Для описания интерфейса G представляют интерес следующие части стандарта ISO 9241 : часть 10 «Принципы диалогового режима», часть 11 «Руководство по использованию», часть
13 «Руководство пользователя», часть 16 «Непосредственное манипулирование объектами в режиме диалога». Организацией МСЭТ разработала стандарты на интерфейсы пользователя в рамках рекомендаций серии МСЭТ
Рек. Z.300 и Z.350.
Из коммерческих стандартов в наибольшей степени отвечает задачам
TMN интерфейс OSF/Motif а также руководство по разработке приложений
для платформы управления Hewlett-Packard Open View. Аналогичные руководства имеют компании IBM (США) под названием общий интерфейс пользователя (сommon user access, CUA) и компания Microsoft Corp.
Основное меню интерфейса пользователя системы сетевого управления
должно соответствовать функциональности системы управления. Например,
пусть система сетевого управления состоит из нескольких OS : OS для
управления сетью SDH, OS для управления сетью PDH, OS для управления
сетью ATM. Тогда главное меню интерфейса каждой OS соответствует общему назначению OS, а второй уровень экранного меню должен отражает
функциональность, которая специфична для каждой OS.
Заполнение в процессе диалога полей данных в экранных формах 
ещё один важный аспект работы интерфейса пользователя. Экранные формы
применяются для сообщения о неисправностях, для ввода параметров при
техническом обслуживании и эксплуатации, для ввода имени и пароля пользователя в момент начала работы с системой управления. Манипулирование
объектами управления предусматривает графическое выделение графических
символов на экране, перемещение символов, соответствующих объектам
управления, по дисплею. Символы на экране условно отображают реальные
физические ресурсы управления. Выделение цветом может означать, к примеру, изменение административного статуса атрибутов объекта с «Доступен» на «Недоступен», что влечёт за собой невозможность вмешиваться в
работу элемента сети для администрации связи.
Цвета играют особую роль при отображении информации управления
на экране рабочей станции. Целесообразно одновременно использовать четыре различных цвета. В таблице 3.6 показаны возможные цвета и их назначение, для кодирования состояния управляемых объектов:
79
Таблица 3.6 – Цветовое решение графического интерфейса пользователя
Назначение
Цвет
Общее
обозначение
Серый
Обозначение
неисправности (отказа)
Красный
Жёлтый
Зелёный
Синий
Применение цветовой кодировки
Базовые символы, нет индикации состояния
объекта (например, технически исправные
объекты)
Критическая неисправность или нештатное
состояние услуги управления
Неисправность, состояние услуг управления
штатное
Неисправность устранена или прекратила
своё действие
Предупреждение или неопределённое состояние (т.е. неисправность не обнаружена, но
рабочий режим нештатный)
Графическое представление сети важно как для управления неисправностями, так и для контроля и управления маршрутами установления соединений. Одна и та же графическая схема сети на экране может быть использована для реализации многих услуг управления. Схема сети должна генерироваться автоматически, на основании сведений о составе, состоянии и размещении управляемых объектов. Схема сети и её элементы периодически обновляются в соответствии с сетевой ситуацией и в связи с изменением состояния управляемых объектов.
На экран рекомендуется вывод не более трёх уровней отображения сети: фоновый рисунок (географическая карта), средний уровень, который
включает объекты с которыми работает оператор и передний план, на который выводятся основные сигналы или данные по управлению. Эти уровни
должны различаться по цвету, яркости, насыщенности и по используемым
цветовым решениям.
Помимо графических изображений в интерфейсе G для взаимодействия
с пользователем используются сообщения. Сообщения могут выдаваться в
следующих формах :
 короткий и ясный текст;
 речевое сообщение (автоинформатор);
 звуковые сигналы.
Пользователь должен однозначно воспринимать и интерпретировать
сообщение. Особый раздел сообщений представляют собой инструкции по
пользованию программой в виде «Help» (раздел меню «Помощь») или в виде
контекстной подсказки. Эти сообщения должны, например, указывать пользователю на то, ввода каких данных ожидает система. Сообщения системы
(системная информация) генерируется системой управления для того, чтобы
пользователь имел представление о текущих заданиях и действиях системы.
Среди сообщений системы можно выделить следующие
80
 уведомления и сообщения о состоянии системы;
 информация о выполняемых заданиях;
 предупреждения т.е. извещение пользователя о потенциальных или
появившихся неисправностях и отказах;
 требование вмешательство пользователя  сообщение о ситуации , в
которой для продолжения действий системы управления требуется
вмешательство пользователя;
 запросы системы  предложение пользователю провести выбор одного из разделов (пунктов) меню.
Интерфейс G – это основной интерфейс для обмена между пользователем и системой сетевого управления. Персонал оператора связи оценивает
функциональность системы сетевого управления по тем возможностям, которые предоставляет пользователю интерфейс G. Поэтому разработка интерфейса G должна проводиться не менее тщательно, чем других интерфейсов
TMN.
3.5 Контрольные вопросы к разделу 3.
1. Для чего предназначена сеть TMN?
2. Перечислите основные компоненты и функциональные возможности TMN.
2. Какие функции выполняет управляющая система OS TMN?
3. Какие уровни описания (виды архитектуры) используются в TMN?
4. В чём разница между функциональным и физическим блоком TMN?
5. Для чего в TMN применяется рабочая станция?
6. Какие функции выполняет агент, а какие функции выполняет менеджер?
7. Какие операции осуществляет менеджер?
8. Какие существуют логические уровни управления?
9. Какие задачи решаются на уровне управления услугами связи?
10. Как взаимосвязаны различные архитектуры управления?
11. Дайте определение функции управления TMN.
12. В чём различие между опорной точкой и интерфейсом TMN?
13. Для управления какими характеристиками АТС используется интерфейс
Q?
14. Какие задачи управления решаются с помощью интерфейса X?
15. Применяется ли к интерфейсу G графический стандарт интерфейсов
пользователя?
81
РАЗДЕЛ 4. ИНФОРМАЦИОННАЯ МОДЕЛЬ УПРАВЛЕНИЯ
ТЕЛЕКОММУНИКАИЦОННОЙ СЕТЬЮ
4.1 Основные компоненты информационной модели
управления
Информационная архитектура TMN, в рамках которой осуществляется
описание объектов управления и обмен данными по управлению, основана на
стандартной модели, предложенной ISO (Рек. МСЭ-Т X.720) и использует
объектно-ориентированный подход. Информационная архитектура TMN оказывает непосредственное влияние на спецификацию интерфейсов TMN.
Ключевыми элементами информационной архитектуры являются информационные элементы, модели взаимодействия элементов и структура информационной модели.
Информационные элементы TMN с точки зрения объектноориентированного подхода и принципов ВОС делятся на управляющие и
управляемые объекты. В дальнейшем рассматривается описание управляемого объекта, как наиболее существенной части информационной архитектуры
TMN. Описание управляемого объекта осуществляется с помощью контура
управляемого объекта (managed object boundary). В контуре указываются характеристики объекта, доступные для управления. Общая структура описания управляемого объекта приведена на рис. 4.1.
Действия
или
операции
Управляемый
Уведомления
объект
(извещения)
или
Атрибуты и
сообщения
поведение
(режимы
работы)
Рис. 4.1 – Описание управляемого объекта
В состав описания управляемого объекта входят :
 атрибуты, которые описывают свойства управляемого объекта;
 операции, которые могут выполняться на объекте по команде;
 поведение или режим работы объекта, который предусмотрен в ответ на поступившую команду;
 сообщения или уведомления, которые выдаются объектом в ответ на
команду.
Управляемый объект наиболее точно характеризуется своим состоянием и взаимоотношениями с другими объектами. Эти характеристики пред82
ставлены в атрибутах управляемого объекта, доступ к которым можно получить с помощью операций/действий, которые осуществляются по команде
управляющего объекта.
При описании управляемого объекта определяется набор уведомлений
(notifications), ответных сообщений (replays) или подтверждений
(acknowledgement), которые посылает управляемый объект для оповещения
управляющей системы о произошедших событиях на объекте.
Описание управляемых объектов достаточно абстрактно и поэтому
может реализовываться по единым принципам для самых разнообразных
элементов сети. МСЭ-Т рекомендует для описания структуры и поведения
управляемых объектов использовать «Общее определение управляемых объектов» (Guidelines for the Definition of Managed Objects, GDMO) согласно
Рек. МСЭ-Т X.722.
Управление в TMN осуществляется с помощью информационной модели взаимодействия типа «менеджер – агент» (см. рис. 4.2).
Управляющая
система
Интерфейс
управления,
напр. Q
Управляющие
команды
(Get,Set,Create)
Протокол
управления
Менеджер
Агент
Уведомления
(notifications),
ответный
сообщения
(replays)
Интерфейс
с MIB
Управляемая система
Фильтрация
мониторинг
Функциональный
интерфейс
Информационная
модель ресурса
с его рабочими
характеристиками
Информационная
модель
ресурса
Управляемые физические
ресурсы
(оборудование связи)
Рис. 4.2 – Взаимодействие менеджера и агента
Считается, что программно-аппаратный комплекс, который выдаёт команды управления и принимает уведомления/сообщения/подтверждения об
исполнении команды, является менеджером. Программно-аппаратный комплекс или программное приложение, установленное на элементе сети (управляемом объекте), которое выполняет команды и посылает сообщения о результатах операций, называется агентом. Менеджер устанавливает сеанс
связи с агентом для осуществления управляющего воздействия. Возможное
нарушение такой связи может быть обнаружено обеими сторонами. Менеджер и агент могут быть физически реализованы в виде отдельного модуля,
платы, процессора с соответствующим ПО или в виде специальной компьютерной программы.
83
Как только связь между менеджером и агентом установлена, может
осуществляться обмен управляющей информацией. С помощью специальных
команд менеджер может потребовать у агента выполнить процедуры «Создать» (Create), «Удалить» (Delete), «Выполнить» (Action) в отношении
управляемых объектов в целом, а также процедуры «Получить» (Get) и
«Установить» (Set) в отношении атрибутов управляемых объектов. Получив
команду на осуществлении той или иной процедуры, агент сначала в информационной модели ресурса, а потом через функциональный интерфейс непосредственно на оборудовании (телекоммуникационном ресурсе) выполняет
необходимую операцию управления. После завершения операции агент посылает сообщение о результатах менеджеру и изме6няет содержимое информационной базы управления. Итак, агент выступает своего рода посредником
между менеджером и управляемым телекоммуникационным ресурсом. При
этом агент через функциональный интерфейс непосредственно взаимодействует с управляемыми физическими ресурсами. Логическое описание ресурсов агент поддерживает с помощью информационной модели ресурса.
В информационной модели ресурса содержатся данные о рабочих характеристиках, на которые можно воздействовать или контролировать в процессе управления. С другой стороны, менеджер также поддерживает информационную модель управляемого ресурса. Поэтому информационные модели
агента и менеджера в основном одинаковы. Однако информационная модель
менеджера может быть более точна в силу того, что информация менеджера
является «очищенной», нормализованной, упорядоченной. Это происходит
благодаря агенту, который фильтрует поток данных в сторону менеджера,
удаляя сведения о незначительных ошибках, искажения, повторах. Кроме
того, информационная модель менеджера включает модели нескольких ресурсов, например нескольких узлов на сети связи.
Сведения информационной модели, которую поддерживает агент, хранятся в базе данных информации управления (management information base,
MIB). Менеджер также поддерживает MIB, но база данных менеджера вторична по отношению к базе данных агента по причинам, которые были перечислены выше. Для обновления своей базы данных менеджер всегда запрашивает агента.
В базе данных MIB информация управления логически упорядочена с
помощью классов управляемых объектов и их характеристик (атрибутов).Под классом понимается множество управляемых объектов с идентичными атрибутами, действиями, поведением. База MIB позволяет хранить
описание действий (операций управления) которые можно осуществлять над
классами управляемыми объектами и описания реакции на эти действия (допустимые режимы работы). Другими словами, база MIB позволяет программным приложениям управления (в первую очередь агентам, затем менеджерам), поддерживать в упорядоченном виде информацию об управляемых
объектах. Важно отметить, что передача управляющих команд чаще основана на модели асинхронной передачи сообщений.
84
Все операции, осуществляемые над управляемым объектом с помощью
MIB, могут быть разделены на 4 примитива (или типа): запросы, ответы,
подтверждения и операции (указания). Эти примитивы используются следующим образом:
1. Чтобы выполнить операцию, менеджер посылает управляющую
команду в виде сообщения-запроса (примитива запроса).
2. Когда сообщение поступает агенту, оно принимается как сообщение-указание (примитив указания).
3. Агент выполняет требуемое действие и посылает сообщение-ответ
в сторону менеджера ((примитив ответа).
4. Сообщение-ответ принимается менеджером как сообщениеподтверждение (примитив подтверждение).
Операции Get, Cancel-Get (отменить получение), Create и Delete подтверждаются всегда; операции Set, Event-Report (сообщение о событии) и Action могут подтверждаться или не подтверждаться. С учетом использования
технологии агент-менеджер, функциональная архитектура TMN имеет вид,
представленный на рис. 4.3.
Итак, в целом информационная модель управления в TMN представляет собой информационную конструкцию, которая включает информационную модель, технологию менеджеров-агентов и базы данных с общими (совместными) знаниям по управлению (shared management knowledge, SMK).
Знания SMK могут быть разделены по нескольким узлам или операционным
системам TMN.
Информационная модель управления представляет собой абстрактное
описание сетевых ресурсов, доступных для управления, и соответствующих
операций по управлению. Информационная модель содержит развёрнутое
описание классов объектов управления, информация о которых хранится в
упорядоченном виде в MIB. Модель определяет стандарты для содержания
информационного массив, который появляется в ходе сетевого управления.
Следовательно, информационная модель и поддерживающая её MIB относятся к прикладному уровню семиуровневой модели ВОС. Поэтому при разработке модели и MIB требуется организовать взаимодействие с другими
приложениями 7-го уровня и нижестоящих уровней модели ВОС, которые
используются для хранения, поиска и обработки информации управления.
85
G
WSF
F
X
A
M
M
A
OSF
OSF
M
X
M
Q
Q
M
Q
Q
A
Q
TF
A
A
TF
M
Q
M
Q
M
A
A
A
A
TF
NEF
TF
NEF
M
M
Рис. 4.3 – Функциональная архитектура TMN, менеджеры и агенты
Информационная модель управления в рамках концепции TMN строится с использованием объектно-ориентированного подхода с формированием отношений наследования, связывания имён и построением диаграмм
«сущность – связь» (Entity Relations Diagrams) с помощью языка UML. В
рамках настоящей книги в качестве базовой рассматриваются Рек. МСЭ-Т
M.3100 от 2005 г. и дополнительные материалы к данной рекомендации.
Анализ данной рекомендации производится с целью выбора классов объектов для реализации системы учёта сетевых ресурсов оператора связи.
«…Общая информационная модель сети необходима для моделирования постоянной ошибки, конфигурации, рабочих характеристик, безопасности и расчета стандартов управления. Общая модель сети определяет характерные ресурсы, которые существуют в сети и их связанные типы атрибутов,
события, действия и поведение. Общая модель сети предоставляет основные
сведения, которые позволяют понять взаимосвязь между этими ресурсами и
атрибутами, и может, в свою очередь, способствовать единообразию в том
случае, если дело касается различных аспектов управления этими ресурсами
и атрибутами» (цитата из официального перевода Рек. МСЭ–Т М.3100, 2005
г. на русский язык). Для упорядочения описания объектов управления технического учёта предложено определенное функциональное распределение
объектов учёта. В частности, с учётом положений концепции TMN, предлагаются следующие группы объектов управления конфигурацией:
 сеть связи в целом;
86
 транспортная сеть
 сеть доступа;
 канал связи;
 средство связи.
Данное разбиение в принципе соответствует концепции управления
TMN, где объектом управления является сетевой элемент. Сетевой элемент
является ключевым компонентом сети, он связан каналами и трактами с другими сетевыми элементами. Таким образом, базовые средства связи могут
быть достаточно полно описаны на основе рассматриваемой модели TMN.
Для описания объекта управления и технического учёта согласно Рек.
МСЭ–Т М.3100 следует выбрать классы управляемых объектов для фрагмента физического оборудования. Описание классов объектов управления, которые в рамках концепции TMN могут быть использованы для организации системы учёта сетевых ресурсов оператора связи, согласно диаграммам UML
на рис. 4.4 и 4.5 приведены далее в таблице 4.1.
Рис. 4.4 – Фрагмент описания конфигурации физического оборудования
в модели TMN
Классы управляемых объектов для фрагмента логического оборудования, которые следует рассмотреть при решении задач технического учёта и
паспортизации показаны на рисунке 4.4.
87
Рис. 4.4 – Фрагмент описания конфигурации логического ресурса в модели TMN
Следует обратить внимание, что в различных редакциях Рек. МСЭ–Т
М.3100 предлагались не только описания конфигурации/состава оборудования связи, но и способы описания каналов и трактов с указанием направления передачи. Принципиально важным здесь является указание диапазона
допустимых значений атрибутов объектов учёта с учётом технических характеристик средств связи, а также совместимость параметров различных
фрагментов устройств управления. Тем не менее, при практическом использовании данной модели на практике могут возникнуть ситуации, когда пользователь по ошибке вводит в описание линейный модуль с заведомо нереальным количеством портов, например линейный модуль со 1000 портами
STM-1. Аналогично, при описании конфигурации оборудования необходимо
учитывать, что, например, карта на 4 порта STM-1 может подключаться к
оборудованию связи как минимум по одному порту STM-4 с учётом возможностей мультиплексирования/демультиплексирования. И, соответственно,
при описании подключения данного элемента к матрице коммутации требуется учитывать указанную характеристику. Поэтому необходимо в полной
мере использовать возможности класса объектов управления «Диапазон значений атрибута» (см. таблицу 4.1).
Следует отметить, что в таблице 4.1 отсутствуют классы объектов
управления для описания физических цепей и линейно-кабельных сооружений связи (пассивного оборудования). Не вдаваясь в подробности, линейнокабельные сооружения можно описать с помощью класса объектов управления [Equipment Holder]. Это допускается с точки зрения функционального
назначения линейно-кабельного сооружения связи. Описание физических
цепей выполнить сложнее. Физическая цепь должна рассматриваться не
только в привязке к физическому порту средства связи но и к линейнокабельному сооружению. Необходимо указать и на то, что при реальном использовании указанных классов объектов управления в таблице 4.1, их описания могут быть расширены и дополнены. В конечном счёте, значение будет
88
иметь реальная информационная модель для объектов учёта и паспортизации, которую разработчик заложит в основу информационной модели TMN.
Таблица 4.1 – Классы объектов управления конфигурацией и технического учета согласно Рек. МСЭ–Т M.3100
89
№ Наименование
№ класса объекта
п/п
1.
2.
3.
Содержательное описание класса объекта
Сеть (Network)
Cовокупность соединённых
и увязанных между собой
физических и логических
ресурсов, способных обмениваться
информацией.
Объекты,
составляющие
сеть, могут иметь общие характеристики, например, по
видам служб/услуг связи
или по типу пользователей.
При этом данная сеть может
являться частью (фрагментом) другой сети.
Диапазон
Позволяет системе управлезначений
ния указывать максимальатрибута
ные и минимальные значеattributeRanges
ния, допустимые для заданного атрибута, а также единичные приращения значения атрибута.
Каждая
сущность
attributeRanges
содержит
диапазон (ряд) значений атрибутов,
принадлежащих
одному классу объектов
управления. Для каждой
сущности ManagedElement,
представляющей
сетевой
элемент, может быть создана одна или несколько сущностей AttributeRanges
Управляемый
Класс объектов управления,
элемент
(объект содержащий описание телеуправления )
коммуникационного обору[Managed Element] дования, которое обеспечивает
функции
объекта
управления, т.е. предоставление услуг электросвязи
пользователям.
Объект
управления
через
Qинтерфейс напрямую или
опосредованно сообщается
с менеджером сети в целях
мониторинга и оперативнотехнического управления.
Содержит в своём составе
оборудование, которое может быть территориально
90
Атрибуты класса
объекта
Атрибутом данного класса является
Идентификатор
сети
[NetworkId] который уникальным
образом обозначает данную сеть.
Атрибутами данного класса объекта управления являются:
attributeRangesId – идентификатор диапазона атрибутов;
kind – вид атрибута;
ranges –дипазон атрибута, выражаемый целым числом, с указанием минимума, максимума и
значения приращения
Связями данного класса управляемого объекта являются:
attributeRanges–managedElement.
Атрибутами данного класса объекта управления являются:
managedElementId – идентификатор управляемого элемента;
systemTitle – системное обозначение элемента;
administrativeState – административный статус (состояние) элемента.
usageState – состояние загрузки
устройства.
Кроме того, здесь следует указать пакеты, связанные с данным
классом :
userLabelPackage – обозначение
пользователя;
vendorNamePackage – имя по-
№ Наименование
№ класса объекта
п/п
Содержательное описание класса объекта
Атрибуты класса
объекта
сосредоточено на одной ставщика оборудования;
площадке или рассредото- versionPackage – версия оборудования;
чено.
locationNamePackage – месторасположение оборудования.
4.
5.
Оборудование
[equipment]
Оборудование
[equipmentR1]
Класс объектов Оборудование [Equipment] представляет описание физических
компонентов
объектов
управления, включая заменяемые компоненты. Оборудование расположено на
одной площадке и может
являться
частью
более
сложного оборудования. В
свою очередь, данный комплект оборудования может
быть разделён на отдельные
подкомпоненты (монтируемые устройства). Оборудование
характеризуется,
прежде всего, типом оборудования. Оборудование может располагаться внутри
другого оборудования, что
подразумевает использование отношений включения
(containment). Если значение одного из перечисленных атрибутов изменяется
(аварийное состояние, список воздействий на объект,
метка пользователя, версия,
местоположение), то в соответствии с Рек. МСЭ–Т
X.721
формируется
уведомление об изменении
значения соответствующего
атрибута.
Класс управляемого объекта, который представляет
производный
класс
от
[equipment]
91
Атрибутами
данного
класса
управляемого объекта являются:
equipmentId – идентификатор
оборудования;
replaceable – данные о заменяемости оборудования.
Согласно Рек. МСЭ-Т X.721 в
случае включения в атрибуты пакета уведомлений об изменении
текущих характеристик [value
change notification package], то
должно автоматически или полуавтоматически
генерироваться
сообщение об изменении версии,
места расположения оборудования.
Пакетами данного класса объекта
управления являются:
userLabelPackage – обозначение
пользователя;
vendorName
Package – имя поставщика оборудования;
versionPackage – версия оборудования;
locationNamePackage – месторасположение оборудования
Связями данного класса управляемого объекта являются:
equipment-managedElement;
equipment-equipment.
Атрибутами
данного
класса
управляемого объекта являются:
serialNumber – идентифицирует
физический ресурс;
supportedByObjectList – значения
данного атрибута идентифицируют множество сущностей, которые способны непосредственно
№ Наименование
№ класса объекта
п/п
Содержательное описание класса объекта
Атрибуты класса
объекта
воздействовать на управляемый
объект. Эти объектные сущности
могут быть как логическими, так
и физическими. Указанный атрибут определяет необходимый
уровень детализации (подробности) описания сущностей, требуемый для управления оборудованием.
Связями данного класса управляемого объекта являются:
equipment-managedElement-R1;
equipment-equipment-R1.
6.
Элемент для
монтажа
оборудования
[Equipment Holder]
Класс объектов управления
«Элементы для монтажа
оборудования» [The Equipment Holder object class]
предназначен для описания
объектов, которые используются для физического
монтажа и установки другого физического оборудования на сетевых элементах.
Примерами могут являться
телекоммуникационные
шкафы, телекоммуникационные стативы и стойки,
сооружения связи.
92
Атрибутами
данного
класса
управляемого объекта являются:
equipmentHolderType – типы элементов для монтажа оборудования;
equipmentHolderAddress – местоположение элементов для монтажа оборудования;
holderStatus – состояние элемента
для монтажа оборудования со
следующими значениями:
пуст – нет смонтированных/
установленных элементов;
содержит допустимые для монтажа/установки элементы, включенные
в
пакет
acceptableCircuitPackTypeList;
содержит элементы, не включенные
в
пакет
acceptableCircuitPackTypeList, но
распознанные сетевым элементом;
содержит нераспознанные монтажные элементы;
subordinateCircuitPackSoftwareLo
ad – описывает программное
обеспечение
упраления
circuitPack,
если
ПО
присутствует.
Пакетом данного класса управляемого объекта являются:
acceptableCircuitPackTypeList –
описывает
типы
групп
фиических
цепей,
которые
№ Наименование
№ класса объекта
п/п
Содержательное описание класса объекта
7.
Группа
физических
цепей
[Circuit Pack]
Класс объектов управления
«Группа физических цепей»
[Circuit Pack] является производным от класса объектов {equipmentR1] в терминах Рек. М.3100 представляет собой заменяемые
монтируемые блоки или
модули, к которым подключены физические цепи. Эти
блоки или модули могут
быть добавлены (вставлены,
установлены) или вынуты
(удалены, демонтированы)
из стативов, стоек, телекоммуникационных
шкафов, монтажных рамок, т.е.
из оконечного кабельного
оборудования сетевых элементов.
8.
Программное
обеспечение
[Software]
Класс объектов управления
«Программное
обеспечение»[Software] представляет
собой логические ресурсы
(программы для ЭВМ) которые хранятся и используются оборудованием связи,
включая базы данных и таб-
93
Атрибуты класса
объекта
допустимы для данного Equipment Holder.
Связями данного класса управляемого объекта являются:
equipmentHolderequipmentHolder.
Атрибутами
данного
класса
управляемого объекта являются:
availabilityStatus (Рек. МСЭ-Т
X.721 ) – указывает на то, корректно смонтирована ли физическая цепь или нет. Значением
данного атрибута может быть
notInstalled [не установлено], в
случае если тип оборудования не
совпадает с допустимым значением. В противном случае данное значение не указывается.
circuitPackType – тип группы физических цепей.
Пакетами данного класса управляемого объекта являются:
сreateDeleteNotificationsPackage –
уведомление о создании или удалении объекта управления;
administrativeOperationalStatesPac
kage – административное и оперативное состояние.
Связи используемые для данного
класса управляемого объекта являются:
circuitPack-equipmentHolderautoCreated;
circuitPack-equipmentHolderexplicitlyCreated;
circuitPack-equipmentHolderautoCreated-R1;
circuitPack-equipmentHolderexplicitlyCreated-R1.
Атрибутами
данного
класса
управляемого объекта являются:
softwareId – идентификатор программного обеспечения;
administrativeState – административный статус (состояние) программного обеспечения.
Пакетами данного класса управ-
№ Наименование
№ класса объекта
п/п
Содержательное описание класса объекта
лицы маршрутизации.
9.
Физический порт
[physicalPort]
Класс объектов управления
«Физический
порт»
[physicalPort] представляет
характеристики физических
окончаний сетевого оборудования для связи с внешней средой. Этот класс объектов является собранием
общих атрибутов физических портов. Целью описания физического порта является предоставление более подробной информации,
в том числе в части описание взаимосвязи между
портом и поддерживаемым
им TTP и (косвенно) CTP.
Если сущность данного
класса рассматривается как
сущность ircuitPackR1, нет
необходимости
использовать
пакет
circuitPackConfigurationPack
age.
описания порта в составе
описания класса объектов
genericTransportTTP.
94
Атрибуты класса
объекта
ляемого объекта являются:
userLabelPackage – обозначение
пользователя;
vendorNamePackage – имя поставщика оборудования;
versionSoftware – версия программного обеспечения.
Связями данного класса управляемого объекта являются:
software-equipment;
software-managedElement;
software-equipment.
Атрибутами
данного
класса
управляемого объекта являются:
physicalPortId – значение номера
(идентификатора) физического
порта;
administrativeState – административное состояние порта;
connectorType – описывает тип
коннектора/разъёма для данного
порта, а именно оптический, проводной или тип, указанный пользователем.
Reach – указывает протяженность по времени или длину переносимого волны/сигнала для
регенерации или терминирования
(завершения распространения)
supportedTTPLis – этот атрибут
указывает ссылки на точки окончания сетевых трейлов транспортного уровня, которые относятся к нижним уровням модели
ВОС
portAssociations – описывает взаимосвязь между портом на мультипортовой группе физических
цепей и другими сущностями
(внешним окружением);
portSignalRateAndMappingList –
этот атрибут обозначает доступную скорость передачи (ширину
полосы пропускания) во взаимосвязи с портом группы физических цепей и загрузкой тракта.
Итак, в информационной модели TMN для достижения целей и решения задач управления конфигурацией принципиально важным является как
максимально полный и достаточно детализированный состав объектов учёта
и паспортизации, так и внутренняя логика, которая не позволяет вводить в
систему заведомо технически некорректные, ложные или неполные сведения.
В этой связи рассмотрим элементы информационной модели TeleManagement
Forum, применительно к системе управления конфигурацией и технического
учёта.
4.2 Информационная модель SID TeleManagement Forum
Информационная модель управления сетью связи, определенная в Рек.
МСЭ–Т М.3100, представляет собой систему взглядов на оперативнотехническое управление сетью электросвязи, построенной на различных
технологиях, средствах связи и видах программного обеспечения. Стандарты, предлагаемые МСЭ-Т, в основном сконцентрированы на уровне сетевого
элемента и на уровне управления сетью связи. Фактически, рекомендации
МСЭ-Т были разработаны на основе подхода «снизу-вверх» – начиная от
управления конкретными настройками сетевого элемента с дальнейшим переходом к управлению сетью связи как сложным техническим объектом.
Этот подход вызывает определённые затруднения у операторов связи на этапе определения экономической эффективности применения систем управления сетями связи.
Кроме того, подход «снизу-вверх» не учитывает всей сложности бизнесзадач оператора связи, связанных с предоставлением/продажей услуг
связи, гарантиями качества услуг. И это несмотря на то, что процессы продаж, договорные отношения с пользователями услуг прямо или косвенно
нуждаются в едином управлении, которое должно быть взаимоувязано с
«технологическим» управлением средствами связи по стандартам TMN. Фактически речь идёт о том, каким образом в реальном времени или в масштабе
времени, близком к реальному, осуществлять мониторинг и управляющие
воздействия на сеть связи и сетевые элементы с тем, чтобы обеспечить возмездное предоставление услуг связи, с сохранением оговоренного качества и
соблюдением мер информационной безопасности, включая безопасность
персональных данных пользователя.
Согласно определению TMF, информационная модель – независимое
от особенностей практической реализации представление важных с точки
зрения бизнеса концепций и сущностей, их характеристик и отношений.
Информационная модель принципиально отличается от других способов хранения данных. Так, словари и базы данных не создают целостного
представления о связях между понятиями, которые в них содержатся. При
этом форма представления данных в базах данных сильно зависит от кон95
кретных платформ и языка, применяемых для их реализации. В текстовых
документах, как правило, используется избыточная и несогласованная терминология. Информационная модель в
то же время позволяет :
 описать взаимодействие и дать визуальное представление сущностей и связей между ними;
 сделать представление информации точным и полным за счет использования нотаций моделирования;
 сформировать единый взгляд на все информационное наполнение
бизнеса.
Преимущества использования единой информационной модели состоят
в следующем:
 создается единый формат сбора и обмена данными как в рамках одного предприятия, так и между различными предприятиями;
 существенно упрощается задача интеграции различных модулей систем управления предприятием;
 возможность ведения единой базы данных для всех бизнеспроцессов позволяет передавать контроль над бизнес-процессом от
одного модуля к другому, что обеспечивает его целостность и
сквозное выполнение;
 обеспечиваются условия для внедрения и ведения корпоративных
каталогов продуктов, услуг и ресурсов, что позволяет получить
полные объективные сведения для анализа;
 эффективности использования ресурсов, оптимальности выстроенной системы продаж, привлекательности предлагаемой продукции
и т.д.
Итак, в целом информационная модель управления в TMN представляет собой информационную конструкцию, которая включает информационную модель, технологию менеджеров-агентов и базы данных с общими
(совместными) знаниям по управлению (shared management knowledge, SMK).
Знания SMK могут быть разделены по нескольким узлам или операционным
системам TMN.
Информационная модель управления представляет собой абстрактное
описание сетевых ресурсов, доступных для управления, и соответствующих
операций по управлению. Информационная модель содержит развёрнутое
описание классов объектов управления, информация о которых хранится в
упорядоченном виде в MIB. Модель определяет стандарты для содержания
информационного массив, который появляется в ходе сетевого управления.
Информационная модель и поддерживающая её MIB относятся к прикладному уровню семиуровневой модели ВОС. Поэтому при разработке модели и MIB требуется организовать взаимодействие с другими приложениями 7-го уровня и нижестоящих уровней модели ВОС, которые используются
для хранения, поиска и обработки информации управления.
96
Системная информационная карта разработана для структурирования
данных, составляющих модель SID.
Разработка TMF информационной модели общей информации и данных (Shared Information/Data, SID) оператора (провайдера) связи позволила
перейти к стандартизации требований к структуре и способам обработки
данных в масштабах OSS данного оператора и при взаимодействии между
различными OSS.
SID предоставляет объединение описаний бизнес-ориентированных
данных в рамках единой информационной модели бизнеса. SID является общей информационной моделью бизнес-данных, наличие которой делает возможным разработку приложений OSS/BSS с интерфейсами, позволяющими
этим приложениям реально взаимодействовать. SID включает объединенную
информационную модель а также описание множества отображения (взаимосвязи) информационной модели на множество моделей данных.
Необходимость применения требований и принципов SID существенно
возрастает в связи с перспективами глобального перехода к услугам NGN. В
связи с этим у пользователей могут возникнуть следующие проблемы :
 Большое количество информационно несвязанных данных, составляющих репозиторий информационной системы. В данном случае под
репозитарием понимается словарь данных т.е. база данных, содержащая информацию о всех составляющих системы OSS – файлы, объекты, отношения между объектами, версии программ, спецификации, кодификаторы.
 Недостатки, связанные с отсутствием общих определений данных для
различных подсистем (компонентов) OSS, что приводит к неэффективности обмена данными и увеличивает затраты на распознавание и нормализацию данных. В частности, принципиально важным является общее для различных приложений описание данных клиентов (пользователей).
 Неурегулированность отношений собственности данных и, как следствие, ответственности за целостность, непротиворечивость, безопасность и актуальность данных и информационных ресурсов OSS
 Дублирование данных различными подсистемами (компонентами)
OSS.
 Неконтролируемое разрастание частных (специфических, нетиражируемых) соглашений между разработчиками различных продуктов, баз
данных для обеспечения возможностей совместного функционирования.
 Недостатки за счёт несовершенства процедур отображения данных той
или иной технологической процедуры на уровень бизнес–процессов и
как результат – отсутствием прозрачности бизнес-процессов.
Наличие сформулированных требований к SID позволяет преодолеть
указанные недостатки за счёт:
97
 Упорядоченной совокупности определений основных бизнес- и системных сущностей, позволяющие описать бизнес- и технологические
процессы телекоммуникационной компании с помощью UMLмоделей.
 Обеспечение общей терминологии, единства определений с помощью
общего словаря-глоссария (классификатора объектов и процессов).
 Описание взаимоотношений между сущностями, в том числе отношений наследования, включения.
Подробное описание структуры SID содержится в документе TMF
GB922 «SID Business View: Concepts & Principles». Release 6.0 version 6.1.
November 2005. В этом документе отражается как бизнес-подход к SID, так и
системные требования к структуре и содержанию SID.
В документе TMF GB922 и главное, приложения к этому документу,
содержатся описания общих и единичных бизнес-сущностей, в частности тех
из них, которые охватывают различные домены и политики оператора в отношении оказания услуг (по аналогии с политиками в области качества).
В центре внимания системного вида SID – моделирование данных, связанных с системными процессами. Если для бизнес-вида на первый план выходят свойства информационных сущностей, важные для бизнеса компании,
то системный вид углубленно изучает отношения между ними, иерархию
классов, особенности интегрирования в архитектуру сети и т.д. Здесь расширяется арсенал используемых средств моделирования и добавляется описание поведения объектов. Тем не менее, системный вид не занимается вопросами реализации моделируемых объектов. Как и для бизнес-вида, информационная модель, лежащая в его основе, не зависит от конкретного исполнения.
Системный вид модели SID, как и бизнес-вид, является объектноориентированным. Центральным понятием для него является объект, характеризуемый набором атрибутов, поведением и взаимодействием с другими
объектами. Схожие по характеристикам объекты объединены классы, организованные в иерархию. Поведение объектов определяется методами, которые можно использовать для изменения режима функционирования того или
иного объекта. Взаимодействие реализуется через различные отношения
между объектами, которые в системном вид SID изучаются наиболее подробно. И если для бизнес-вида SID моделирование отношений не являлось
основной задачей, то в системном виде, как правило, они детально рассматриваются как отдельный класс–ассоциация.
Системный вид SID определяет и такое важное с точки зрения жизненного цикла объекта понятие, как ограничение. Ограничения семантически
выражают условия внешней среды, влияющие на объект. Например, объект
может быть создан только после некоторого события произошедшего в системе. Информация о подобных свойствах представляется в модели при помощи ограничений, выраженных на языке OCL (Object Constraint Language).
98
В различных приложениях к основному документу TMF GB922 «SID
Business View: Concepts & Principles» содержатся рекомендации по структуре
SID в отношении продуктов, пользователей и учёта физических ресурсов (Inventory Management).
При этом каждое описание структуры данных SID нормализовано и
выстроено по определенному плану, который включает в себя разработку пояснений к структуре, определения бизнес-сущностей и UML-модели; словари
(глоссарии) и классификаторы, которые включают в себя описание всех
классов, атрибутов, взаимосвязей между классами и т.п.
Общий перечень бизнес-сущностей, разработанных в рамках SID представлен на рис. 4.5.
Как видно на рис. 4.5, каждый домен SID содержит некоторое количество агрегированных бизнес-сущностей (Aggregate Business Entities, ABEs.)
Каждая ABE является своего рода «контейнером» для набора бизнессущностей, относящихся к соответствующей области управления. Каждая
бизнес-сущность содержит неделимые (элементарные) бизнес-сущности и
ассоциированные с ними атрибуты. Используя разбиение по уровням, существенной множество информации может быть представлено (распределено) в
виде понятных, доступных для использования областей управления.
Для описания каждой информационной сущности в SID используются
две таблицы. В первой таблице (рис. 4.6) приводится текстовое описание
сущности, перечисляются модели, в которых данная сущность также определена, а кроме того, указаны классы, с которыми сущность взаимодействует. В
таблице помимо этого предусмотрено поле для описания правил использования и реализации сущности, но в текущем релизе спецификаций SID это поле
не заполнено. Предполагается, что это будет сделано по мере разработки
спецификаций системного вида SID.
99
Рис. 4.5 – Бизнес-сущности SID
Рис. 4.6 – Табличное описание сущности «Спецификация телекоммуникационного продукта»
Таблица 4.7 характеризует атрибуты сущности. В нее включают
название и описание атрибутов, тип данных, признак обязательности / необязательности, особенности использования и замечания (указываются в произвольной форме).
100
Рис. 4.7 – Табличное описание атрибутов сущности «Спецификация телекоммуникационного продукта»
Рис. 4.8 – Схема функциональных взаимосвязей между бизнессущностями SID
101
Пример взаимосвязи между элементарной бизнес-сущностью «Customer name» (Имя пользователя) сущности Customer (Пользователь) в составе
SID и источником данных об имени пользователя Name во внешнем источнике данных Data Source (например, паспортный стол) представлен на рис.
4.9. Такая взаимосвязь получается в процессе трансляции общей модели SID
в модель данных, о чём будет сказано ниже.
Рис. 4.9 – Взаимосвязь бизнес-сущности SID и источника (базы) данных
Сущности системного вида, как правило, являются расширением сущностей бизнес-вида SID. Так, в системном виде модели к существующим
классам могут быть добавлены новые атрибуты и методы, отношения – преобразованы в отдельный класс, определены ограничения. Для моделирования
системных аспектов вводятся новые классы, типы шаблонов, интерфейсы.
Кроме того, дополнительная информативность может быть достигнута за
счет применения более широкого набора средств моделирования UML.
По аналогии с TMN, информационная модель управления TMF принимая во внимание необходимость учёта разнообразных сетевых ресурсов,
строится с использованием объектно-ориентированного подхода. Перечень
классов объектов управления, которые могут быть использованы для организации системы учёта сетевых ресурсов организаций связи, приведены в таблице 4.2.
102
Таблица 4.2 – Объекты управления и учёта согласно рекомендациям
TeleManagement Forum
№
Наименование
Атрибуты класса объекта для использова№
класса объектов
ния при управлении конфигурацией
п/п
1.
Агент [Agent]
Поддерживает интерфейсы взаимодействия
TMF. Может иметь версию и описание вида
ПО, в котором реализован агент управления.
2.
Цепь
Используется для описания среды переноса
(физическая)
информации по схеме «точка-точка». Объект
[Circuit]
может находиться в следующих состояниях:
разрешённое для использования;
Примечание. По разрешённое для использования;
смыслу
понятие активное (рабочее).
«Цепь» здесь ис- Административные состояния:
пользуется
как заблокировано;
«Тракт» (link). Бо- закрыто;
лее близким по разблокировано.
смыслу к опреде- Может содержать описание оконечных точек
лению цепи как (концов тракта), данные о пропускной способпровода – физиче- ности цепи, идентификатор цепи, сведения о
ской среды – здесь направления передачи, имена компонентов цеявляется понятие пи.
[Facility]
Включает описание функций обработки дан3.
Вычислительная
ных, периферийной памяти, файлов.
система
[Computer
Описывается атрибутами административного и
рабочего состояния, идентификатором систеsystem]
мы.
4.
Средства
Включает описание физических средств для
переноса
переноса сигнала электросвязи, с помощью которых организуется соединение. Физические
[Facility]
средства переноса могут находиться внутри
других средств. Например, здесь может быть
описана пара проводов в кабеле связи, а сам
кабель может быть описан в классе объектов
«Тракт».
5.
Запись о
Включает общую информацию, которая отрасобытии
жает события, происшедшие на сети. Сюда
[event Record]
может записываться информация об изменении
состава учитываемых объектов:
событие, состоящее в добавлении к объекту
103
№
№
п/п
Наименование
класса объектов
6.
Контакт [Contact]
7.
Заказчик
[Customer]
8.
Функция
[Function]
9.
Журнал событий
[Event log]
10.
Объект сетевого
протокола, не требующего соединения
[clNetwork
Protocol Entity]
12.
Местоположение
[Location]
Атрибуты класса объекта для использования при управлении конфигурацией
нового компонента;
сигнал тревоги;
изменение значения параметра учёта;
снятие объекта с регистрации;
прохождение регистрации объектом;
перерегистрация объекта;
удаление значения параметра объекта учёта.
Идентификация контакта для связи с лицами
или организациями, ответственными за данную
единицу учёта (класс или подкласс объектов).
Содержит идентификационные данные заказчиков, которые используют данную единицу
учёта (класс объектов) для получение/оказания
типа или типов услуг электросвязи (с указанием типов услуг).
Описывает функции, которые реализуются
данной классом объектов управления. Параметры данного класса предоставляют информацию о рабочем, административном состоянии объекта, связаны с именами заказчиков и
контактами, содержат имена объектов, которые
имеют дело с конкретным оборудованием, сетями и вычислительными системами.
Содержит записи о событиях на сети, связанные с объектом учёта, данные о критериях, по
которым сведения о событии были зафиксированы в журнале.
Определяет класс объектов и их параметры
(атрибуты), связанные с сетевым протоколом,
не требующим соединения, например протокол
IP. Параметры (атрибуты) включают:
адрес локальной сети или выделенный IPадрес;
число отосланных, принимаемых, повторенных
и отброшенных PDU.
Могут включать сведения об изготовителе, серийном номере устройства являющегося объектом.
Идентифицирует местоположение одного или
более объектов или лиц. Параметры (атрибуты)
104
№
№
п/п
Наименование
класса объектов
13.
Оборудование
[Equipment]
14.
Фирмаизготовитель
[Manufacturer]
15.
Сеть
[Network]
16.
Поставщик услуг
электросвязи
[provider]
Атрибуты класса объекта для использования при управлении конфигурацией
данного класса объектов включают:
географические координаты;
идентификаторы местоположения;
адреса местонахождения, в частности почтовые
адреса.
Включает описание оборудования и средств
связи внутри сети.
Атрибуты данного класса включают:
идентификаторы заказчиков;
тип оборудования;
название фирм-производителей оборудования;
названия услуг, оказываемые с помощью оборудования;
указание версии ПО управления;
иную информацию, относящуюся к данному
оборудованию.
Класс объектов используется для идентификации и описания любой организации, которая
производит учитываемые сетевые ресурсы.
Параметры (атрибуты) включают:
имена
контактного
персонала
фирмыизготовителя;
средства контакта с изготовителем – телефон,
факс, e-mail;
идентификаторы фирм-производителей.
Включает описание физических или логических объектов, которые поддерживают передачу информации между пользователями.
Параметры (атрибуты) включают в себя:
идентификатор сети;
описание назначения сети;
перечень типов и видов услуг связи; предоставляемых сетью;
перечень объектов учёта на сети связи.
Используется для описания организации или
оператора связи, ответственно за предоставление услуг связи и иных сервисов.
Параметры (атрибуты) включают:
идентификатор поставщика услуги;
перечень услуг;
105
№
№
п/п
17.
Наименование
класса объектов
Услуга [service]
Атрибуты класса объекта для использования при управлении конфигурацией
описания полномочий поставщика.
Включает атрибуты, имеющие отношение к типам услуг сети/услуг связи, которые поставляются клиентам с использованием имеющихся
сетевых ресурсов.
К параметрам (атрибутам) услуги относятся:
идентификатор услуг;
имя поставщика;
имена клиентов;
средства предоставления услуги;
типы и виды предлагаемых услуг.
В целом имеющаяся информационная модель TMF в некоторой степени соответствует объектам информационной модели согласно рекомендациям TMN МСЭ-Т. Это относится прежде всего к таким объектам как «Сеть»,
«Оборудование», «Соединение тракта». Однако модель TMN можно рассматривать как более «гранулированную» в отношении описания оборудования связи, в частности таких объектов как фрагмент описываемого оборудования.
Информационная модель согласно TMF является коммерчески направленной и отражает существенные моменты, связанные с пропуском и учётом
объёмов трафика, сведения о поставщиках оборудования и услуг связи, данные о заказчиках/потребителях услуг. Другими словами, если модель TMN
ориентирована на физические ресурсы, то модель TMF в равной степени
включает как физические, так и логические ресурсы.
4.3 Контрольные вопросы к разделу 4
1. Что включает описание управляемого объекта?
2. Какой управляющей информацией обмениваются агенты и менеджеры?
3. Определите, что такое «класс управляемых объектов»?
4. Для чего нужна общая информационная модель сети?
5. Какие существуют классы объектов управления?
6. В чем преимущества использования единой информационной модели сети на основе SID?
7. Какие существуют объекты управления, рекомендованные
TeleManagement Forum?
106
РАЗДЕЛ 5. КАРТА ПРОЦЕССОВ ТЕХНИЧЕСКОЙ
ЭКСПЛУАТАЦИИ ETOM ОПЕРАТОРОВ СВЯЗИ
5.1 Бизнес–процессы и формирование карты ETOM
В центре внимания расширенной карты процессов технической эксплуатации enhanced Telecom Network Operation Map, eTOM находятся бизнеспроцессы, используемые сервиспровайдерами (операторами связи),
связи между этим процессами, идентификация необходимых интерфейсов и
использование информации пользователя (customer), услуги (service), ресурса
(resource), поставщика/партнёра (supplier/partner) многими процессами.
Перечисленные понятия были введены в документе версии 2000 г., а
также включены в приложение к eTOM. Наиболее важные понятия, необходимые для понимания новых задач управления с точки зрения бизнеса операторов связи, выглядят следующим образом:
 пользователем считается субъект, использующий услуги, предоставляемые провайдером;
 провайдер, или сервиспровайдер  это компания или фирма, основной бизнес которого состоит в предоставлении телекоммуникационных услуг/услуг электросвязи;
 оператор  это организация или компания, которая использует телекоммуникационную инфраструктуру. Оператор также может
быть провайдером, что характерно для базовых услуг связи (местная и междугородная телефония, услуги документальной электросвязи);
 услуга  разрабатывается сервиспровайдером для продажи в составе продуктов. Одни и те же услуги могут включаться в несколько
продуктов, но в различном сочетании;
 ресурс  представляет собой физический или нефизический компонент, используемый при создании услуги, и включает элементы сети, программное обеспечение, информационные системы и технологические компоненты;
 поставщик/партнёр  компания или организация связи, предоставляющая свои услуги или продающая товары/продукты оператору
связи;
 процесс  описывает систематизированное последовательное множество функциональных действий (функций), которые завершаются
определённым результатом или выходными данными.
Здесь следует оговориться, что в рамках современного представления о
бизнеспроцессах под продуктом (product) в телекоммуникациях понимается
потребительская ценность, которую сервиспровайдер предлагает клиентам
107
или пользователям. В свою очередь услуга или сервис (service) отражает элементы и детали предоставления и поддержки продукта для пользователя.
Основные положения по управлению телекоммуникациями рассматриваются в рамках документа, сокращённо именуемого eTOM (enhanced
Telecom Operations Map) который ныне является частью рекомендации МСЭ–
Т М.3050.
Документ eTOM базируется на Telecom Operations Map (технологическая карта эксплуатации). Документ eTOM расширяет определённые положения TOM в направлении общей производственной схемы предприятия/компании связи и тех изменений, которые происходят с учетом влияния
электронного бизнеса (ebusiness). Большинство положений eTOM получены
путём обобщения практического опыта многих провайдеров и операторов
связи. В центре внимания документа eTOM находятся бизнеспроцессы, используемые сервиспровайдерами (операторами связи), связи между этим
процессами, идентификация необходимых интерфейсов и использование информации пользователя (customer), услуги (service), ресурса (resource), поставщика/партнёра (supplier/partner) многими процессами.
Здесь следует оговориться, что в рамках современного представления о
бизнеспроцессах под продуктом (product) в телекоммуникациях понимается
та потребительская ценность, которую сервиспровайдер предлагает клиентам или пользователям. В свою очередь услуга или сервис (service) отражает
элементы и детали предоставления и поддержки продукта для пользователя.
Следует отметить, что трактовка понятия «ресурс» в определении рекомендаций МСЭ–Т и документов TMF является схожей.
Документ eTOM включает в себя описание схемы бизнеспроцессов
оператора связи (eTOM Business Process Framework), а именно:
 собственно бизнеспроцессы сервиспровайдера;
 общие определения для описания схемы бизнеспроцессов;
 соглашения о том, какая базовая информация требуется для осуществления процесса, подпроцесса; эта информация используется в
качестве исходных данных для разработки бизнестребований к системе управления и информационной модели, включая информационную модель учёта сетевых ресурсов.
Схема процессов в виде многоуровневой схемы.
Общее представление схем бизнеспроцессов в документах TMF и Рек.
МСЭ–Т М.3050 представлено на рисунке 5.1. Здесь показан так называемый
0-й уровень представления схем бизнеспроцессов (eTOM Business Process
Framework  Level 0 Process). Эта схема демонстрирует самое общее представление процессов оператора связи. При этом все процессы поделены на
две общие (вертикальные) группы: в первой группе сосредоточены процессы,
определяющие стратегию развития оператора, жизненный цикл его инфраструктуры и услуг (продуктов); во второй группе находятся процессы эксплуатации, которые осуществляет оператор или сервиспровайдер.
108
Как видно из схемы на рисунке 5.1, управление ресурсами начинается
на стадии определения стратегии развития инфраструктуры, и продолжается
на всех стадиях её жизненного цикла ресурса. В настоящей книге далее рассматриваются вопросы управления конфигурацией и учёта ресурсов в части
использования ресурсов по назначению. Разумеется, учёт ресурсов может
рассматриваться и в рамках стратегического управления (учёт основных
фондов) и в рамках средне- и долгосрочного планирования развития инфраструктуры, но эти вопросы детально обсуждаться не будут.
Рис. 5.1 – Уровень 0 представления схемы бизнеспроцессов оператора
связи
По горизонтали на рис. 5.1, в виде четырёх уровней, представлены
функциональные области, которые включают функции, обеспечивающие выполнение бизнеспроцессов от начала стратегического планирования до расчётов за предоставленные услуги с пользователями и поставщиками.
Внизу на схеме рис. 5.1 указана ещё одна область процессов, оказывающих непосредственное воздействие на две верхние области: управление
производством, акционеры, персонал, поставщики услуг для оператора,
партнёры. Разделение на вертикальные группы и горизонтальные уровни логически объяснимо т.к. успешное завершение процесса обслуживания абонента может зависеть как от типа и возможностей установленного оборудо109
вания связи (что обусловлено планированием, выбором поставщика, задействованными ресурсами), так и от используемых оператором технологических операций, например процедур технической эксплуатации, регламента
использования средств связи.
Документ eTOM и Рек. МСЭ–Т М.3050 описывают сами процессы и
точки/способы взаимодействия процессов прежде всего для выполнения процессов обеспечения готовности услуги (Readness), исполнения т.е. фактического предоставления услуги (Fulfillment),
гарантирования услуги
(Assurance), расчётов за предоставление услуг связи (Billing). Каждая из перечисленных групп процессов в свою очередь состоит из законченных цепочек процессов.
В документе eTOM Рек. МСЭ–Т М.3050 не рассматриваются вопросы о
целевой группе клиентов, на которую ориентируется сервиспровайдер, о
сегменте рынка, в котором будет работать оператор связи, нет описания миссии сервиспровайдера, программы предоставления услуг, оценки стоимости
услуг, описания схем финансирования телекоммуникационных проектов.
Схема бизнеспроцессов относится, прежде всего, к стратегической модели
бизнеса сервиспровайдера. Данное описание бизнеспроцессов способствует бизнесреинжинирингу деятельности оператора в меняющихся условиях
рынка. В документах TMF по eTOM дополнительно разработаны процессы
низкого уровня 2 и 3. Результат работ представлен на рисунке 5.2.
110
Рис. 5.2 – Уровень 1 представления схемы бизнеспроцессов оператора
связи
Здесь уровень 0 разбит на отдельные процессы уровня 1. В свою очередь, каждый из процессов на рисунке 5.2 декомпозирован на более детальные процессы (уровень 2,3), с которыми собственно и имеет дело подавляющее большинство сотрудников компаний связи и провайдеров.
На рисунке 5.2 показано семь групп процессов, сгруппированных по
вертикали. Это сквозные (endtoend) процессы, которые охватывают несколько функций и требуются как для поддержки пользователей услуг, так и
для управления бизнесом оператора связи. С этой точки зрения центральными здесь являются процессы эксплуатационной поддержки пользователей
(customer operations processes), которые объединены под общей аббревиатурой FAB (Fulfillment, Assurance, Billing). При этом процессы эксплуатационной поддержки и обеспечения готовности ресурсов (Operations Support &
Readiness, OSR) в предлагаемой схеме функционально отделены от FAB.
Это вызвано тем, что процессы, составляющие FAB, происходят в реальном масштабе времени и описываемое функциональное разделение подчёркивает необходимость автоматизации процессов FAB для постоянной и
своевременной поддержки пользователей. Процессы FAB имеют прямые интерфейсы с пользователями услуг связи и находятся в центре производственной деятельности оператора связи.
Стратегия развития (Strategy & Commit), управление жизненным циклом (ЖЦ) инфраструктуры (Infrastructure Lifecycle Management) и управление
жизненным циклом продуктов (Product Lifecycle Management) объединены в
рамках группы Стратегия, инфраструктура, продукт (Service, infrastructure
and product, SIP). Они, в отличие от эксплуатационных операций, не связаны
с непосредственной поддержкой пользователей и не функционируют в реальном масштабе времени. Для создания инфраструктуры телекоммуникаций, строительства зданий и сооружений требуются месяцы и годы, в то время как для проверки состояния счёта пользователя перед установлением сеанса связи требуются секунды.
Процессы SIP необходимы для гарантии того, что эксплуатационные
процессы пользователя (customer оperations processes) полностью отвечают
требованиям клиента, в том числе в части сроков предоставления, стоимости,
уровня поддержки и доступности услуги.
Например, развитие системы сигнализации ОКС№7 как стратегическое
направление совершенствования инфраструктуры сделало возможным
предоставление услуги междугородной видеоконференцсвязи по технологии
ЦСИО (только цифровизации магистральной первичной сети было недостаточно). Процессы SIP не имеют прямых интерфейсов с пользователями услуг
связи, хотя и критически важны для производственной деятельности предприятия связи в целом.
111
Cхема уровня 2, получаемая из схемы уровня 1 для процессов управления и эксплуатации имеет вид (см. рисунок 5.3) согласно Рек. МСЭ–Т
M.3050.2. Представленные процессы на рис. 5.3 обеспечивают поддержку в
актуальном состоянии знаний и информации о доступных ресурсах и возможностях по управлению используемыми ресурсами для предоставления и
поддержки услуг связи запрашиваемых или предлагаемых пользователям
услуг связи. Сюда же относятся все процессы, связанные с функциями сквозного управления ресурсами оператора связи по принципу «из конца – в конец» при предоставлении услуг. Одна из базовых функций – сбор информации из сетевых элементов или СУЭС о наличии и состоянии ресурсов; в
дальнейшем осуществляется интеграция, коррелирование и предоставление
собранных данных в виде соответствующей информации для систем управления услугами или бизнес-систем. Функциональное содержание процессов
на рисунке 5.3 следующее.
Рис. 5.3 – Уровень 2 описания управления и эксплуатации сетевых ресурсов
Управление и эксплуатации для поддержки и обеспечения готовности ресурсов (resource management and operation support and readness)
предназначены для управления ресурсом (ресурсами) инфраструктуры, чтобы обеспечить доступность программных приложений, ресурсов вычислительной техники и сетевых ресурсов для поддержки процессов FAB. Эти
процессы обеспечивают контроль работоспособности ресурса на объектах
ввода с целью проведения анализа доступности и производительности (эксплуатационных качеств) используемых ресурсов во времени, включая анализ
трендов и прогнозирование. Осуществляется управление качеством технического учёта включенных ресурсов. Осуществляется проактивный менеджмент, формирование и управление потоками работ (заданий) для поддержки
процессов eTOM. В рамках данных процессов осуществляется управление
ремонтными работами, заменой и восстановлением оборудование, транспортировка и распределение ресурса.
Обеспечение ресурсов (resource provisioning) – здесь осуществляется
комплексная подготовка физического и логического ресурса для индивидуальных пользователей или групп (категорий) пользователей, включая определение местоположения указанного ресурса, его инсталляцию, конфигурацию, активацию, восстановление после повреждений, тестирование на пред112
мет соответствия условиям на предоставление услуг или в ответ на запрос от
других процессов для снижения неблагоприятных последствий от кратковременного уменьшения ёмкости доступных ресурсов, в том числе при неисправностях или отказах оборудования. При осуществлении данного процесса может осуществляться обновление сведений о техническом учёте ресурса.
Все изменения по ресурсу, который используют те или иные пользователи,
должны отражаться в базе данных сетевых ресурсов.
Управление при повреждении ресурсов (resource trouble management)
– процессы предусматривают регулярный, постоянный мониторинг сообщений о технических, технологических или административных проблемах и повреждениях, имеющихся с использованием ресурса с целью получить информацию о степени эффективности использования ресурса. Суть состоит в
опережающем решении проблем, ещё до того, как появятся претензии или
жалобы пользователей. Сюда же относятся процессы восстановления после
повреждений, генерация сообщений обо всех этапах и реализуемых процессах, включая трассирование работ по ремонту и восстановлению, а также соответствующие сообщения в сторону пользователей и системы управления
услугами.
Анализ эксплуатационных качеств (производительности) ресурсов
(resource performance management) – в рамках данных процессов осуществляется комплексный контроль, мониторинг, анализ эксплуатационных качеств
и характеристик ресурса. Эти процессы предусматривают контроль своевременного восстановления эксплуатационных (рабочих) характеристик ресурса
до уровня, предусмотренного качеством предоставления услуги.
Сбор и распространение данных о ресурсе (resource data collection
and distribution) – данные процессы предусматривают объединение сведений
об интенсивности использования ресурса, сведения об эксплуатационном состоянии ресурса для остальных процессов. Данные процессы связаны со сбором и обработкой информации от различных источников, поэтому здесь реализуются процедура фильтрации, агрегации, форматирования, преобразования и корреляции по отношению к информации, которая будет доступна
другим процессам. Для целей настоящей книги наиболее важным является
декомпозиция процесса управления и эксплуатации для поддержки и обеспечения готовности ресурсов. Это процесс декомпозируется до уровня 3 в соответствии с рисунком 5.4.
Управление инфраструктурой ресурсов обеспечивает готовность и доступность соответствующих программных приложений, ресурсов вычислительной техники и сетевых ресурсов для поддержки процессов исполнения
услуги, гарантии услуги и расчётов за услугу. Здесь же реализуется мониторинг и формирование отчётов о возможностях и стоимости ресурсов для
процессов FAB. Содержание процессов в соответствии с рисунком 5.4 имеет
вид:
Наличие возможности обеспечения работы (запуска) ресурса
(enable resource provisioning) – данные процессы предназначены для плани113
рования и внедрения новой или модернизация существующей инфраструктуры с тем, чтобы существовала возможность поддержки
Рис. 5.4 – Уровень 3 описания процесса «Управление и эксплуатация для
поддержки и обеспечения готовности ресурсов»
процессов обеспечения ресурсов, а также процессов мониторинга, управления и отчётности о возможностях процессов обеспечения ресурсов. Сюда
включаются планирование и управление ёмкостью, в том числе сети связи,
определение и мониторинг организационных процессов; создание внедрение,
модификация и обновление средств, с помощью которых формируется необходимая инфраструктура, в том числе технический учёт ресурсов. Этот же
процесс используются для разработки и применения процедур технической
эксплуатации, мониторинга используемой ёмкости, управления восстановления ресурсов, обновления сведений технического учёта ресурсов при любых
изменениях доступной ёмкости инфраструктуры ресурсов.
Управление техническим учётом (инвентаризацией) ресурсов
(manage resource inventory) – возможности этих процессов проявляются
прежде всего в формировании, управлении и администрировании ресурсами
предприятия, что материализуется в виде базы данных технического учёта
ресурсов RID (Resource Inventory Database). Также указанные процессы обеспечивают отслеживание и информирование пользователей о степени использования, доступе и качестве информации по техническому учёту ресурсов.
Технический учёт ресурсов поддерживает записи обо всех ресурсах инфраструктуры и конфигурациях ресурсов, версиях и детальном состоянии. Также
производится запись результатов тестов и испытаний и прочей информации,
связанно с ресурсами, для обеспечения поддержки процессов RM&O и иных
процессов. Также технический учёт ресурсов обеспечивает взаимосвязи меж114
ду услугами (сервисами) и ресурсам, создавая в результате процессы управления обеспечения ресурсов.
Наличие возможности управления эксплуатационными качествами ресурсов (enable resource performance management) предполагает поддержку процессов управления рабочими характеристиками, эксплуатационными качествами ресурсов с помощью проактивного мониторинга и оценку
производительности ресурсов инфраструктуры. Здесь же осуществляется мониторинг, управление и генерация отчётности о возможностях процессов
управления рабочими характеристиками ресурсов. Формируются пороговые
значения производительности ресурсов, проводится анализ трендов, результаты анализа регистрируются в репозитории.
Поддержка управления при повреждении ресурса (support resource
trouble management) – привентивные действия на основе собранной статистики повреждений, проводимые согласно плану работ, срочные ремонтные работы, мониторинг, управление и формирование отчётности по соответствующим процессам. Процесс включает разработку и осуществление плана соответствующих организационно-технических мероприятий и поддержку
процессов управления проблемами с предоставлением услуг.
Наличие возможности сбора и распространение данных о ресурсах
(enable resource data collection and distribution) – администрирование и управление процессами, позволяющими осуществлять эффективные операции по
сбору данных о ресурсах и распространение данных об инфраструктуре, а
также мониторинг и формирование отчётности по указанным процессам.
Управление потоками работ (заданий) (manage workforce) – включает планирование, назначение, диспетчеризация и управление работами и организацией деятельности персонала оператора связи. Руководство оператор
связи напрямую управляет данными процессами а также осуществляет непрямой контроль деятельности третьих лиц, имеющих отношение к бизнес
предприятия.
Управление логистикой (manage logistics) – включает управление
складским запасами, управление товарными запасами, транспортировку оборудования и покупных изделий на объекты заказчика.
Как видно из рис. 5.4, процессы технического учёта ресурсов в первую
очередь поддерживают процессы того же уровня 3 RMO. Однако в рамках
комплексной системы управления предприятием возможна поддержка других процессов в горизонтальной группировке управления ресурсами и процессов верхнего уровня – управление услугами.
Декомпозиция бизнеспроцессов полезна как для операторов связи, так
и для сервиспровайдеров, поскольку позволяет сделать бизнес более эффективным, упорядочить собственные технологические процессы, успешно
применять программное обеспечение, разработанное третьей стороной, без
затрат на существенную адаптацию. При этом рекомендации eTOM относятся прежде всего к бизнесу традиционных операторов связи с возможным
расширением решений для электронного бизнеса.
115
5.2 Назначение уровней eTOM в области технической
эксплуатации
Процессы, описанные в eTOM, не относятся к бизнесмодели сервиспровайдера или оператора связи. В eTOM не рассматриваются вопросы о
целевой группе клиентов, на которую ориентируется сервиспровайдер, о
сегменте рынка, в котором будет работать оператор связи, нет описания миссии сервиспровайдера, программы предоставления услуг, оценки стоимости
услуг, описания схем финансирования телекоммуникационных проектов.
Схема бизнеспроцессов относится прежде всего к стратегической модели
бизнеса сервиспровайдера. Данное описание бизнеспроцессов способствует бизнесреинжинирингу деятельности оператора в меняющихся условиях рынка. Модели высшего уровня, как правило, не имеют особой практической ценности для многих участников рынка телекоммуникаций и сотрудников среднего звена администраций связи, поэтому в документе eTOM разработаны процессы низшего уровня.
Предлагаемая схема позволяет оператору связи или сервиспровайдеру
отойти от ориентации только на предоставление услуг или пресловутой «заботы об абоненте» в пользу управления взаимоотношениями с пользователями. Это позволяет делегировать ряд полномочий по управлению оконечного
оборудования пользователю или партнёру, внедрять сетевое управление и
контроль со стороны пользователей, повышая таким образом долю и уровень
участия клиентов в деятельности предприятий связи.
Уровень управления взаимоотношениями с клиентами в логической
многоуровневой архитектуре управления отвечает главным образом за поддержку развития, управления и жизненный цикл продуктов. Главным назначением уровня являются:
 управление реализациями объектов продукта на протяжении всего их
жизненного цикла;
 предоставление общих функциональных возможностей для управления
заказами продуктов поставщиков услуг;
 предоставление функциональных возможностей для обслуживания
диалога с клиентами посредством четко определенного бизнесинтерфейса;
 администрирование и управление функциональными возможностями,
использующими информацию, поступающую с уровня управления обслуживанием. Например, обработка карточки повреждений, сбор и обработка данных учета на уровне продукта и/или клиента.
Функции, которые должны содержаться в уровне управления рынком,
продуктом и клиентами, могут включать, например, определение самого
продукта с точки зрения маркетинга и с коммерческой точки зрения, как вы116
ставлять счета, на кого направлено обслуживание, имеются ли конкретные
географические зоны, в которых обслуживание не может быть предоставлено,
группирование услуг и т. д.
Уровень управления и операции обслуживания поддерживает функции управления доставкой обеспечением конечных пользователей услугами в
соответствии с ожиданиями клиентов и включает следующие функции:
 управление профилями обслуживания: каждый профиль обслуживания
выражает требования по транспортным ресурсам и ресурсам обслуживания, необходимым для активации
 обслуживания; расположенные ниже уровни отображают эти требования параметры сети расположенных ниже сетевых элементов;
 управление связями существующих абонентов с набором профилей,
соответствующих договорам об обслуживании абонентов;
 управление ресурсами обслуживания и транспортными ресурсами, необходимыми обеспечения возможности активации услуг в соответствии с договором с конечным пользователем, включая требуемую
возможность установления соединения и связанные ней характеристики: пропускная способность, QoS, уровень СУО;
 наблюдение за активными услугами для гарантии их соответствия
условиям СУО воздействием несоблюдения параметров на функции
выставления счетов (доставка информации оператору, указание системе выставления счетов о возврате переплаты в случае слишком низкого
QoS и т. д.).
Все функции управления, которые показаны относящимися к управлению эталонными точками поставщика в направлении уровня управления
рынком, продуктом и клиентами, являются
независимыми с отношении ресурсов/технологий и не будут предоставлять
никаких технических
сведений о расположенных под ними ресурсах, включенных в процесс
предоставления услуг
клиентам: никакая информация о транспортных платформах или платформах
обслуживания
недоступна через функции управления обслуживанием.
Функция управления обслуживанием использует функцию управления
ресурсами для
преобразования ее вида, ориентированного на обслуживание и информации в
требуемые объекты в соответствующих ресурсах.
В то время как уровень управления обслуживанием (УУО) отвечает за
управление жизненным циклом услуг, а также за доставку и обеспечение экземпляров услуг, уровень управления ресурсами (УУР) отвечает за управление логической инфраструктурой обслуживания и логической транспортной
инфраструктурой. Функции, являющиеся частью функций управления ресурсами обеспечивают отображение информации, ориентированной на услуги,
117
которая используется функциями управления обслуживанием, в информацию, зависящую от ресурсов/технологий, которая используется ресурсами.
Функция управления ресурсами состоит из двух главных подфункций,
соединенных в месте разделения архитектуры на слой услуг сети и транспортный слой сети:
 функции управления ресурсом обслуживания;
 функции управления транспортным ресурсом.
Функция управления ресурсом обслуживания предоставляет функциональную возможность управления для нового набора характеристик управления ресурсами, относящихся к поддержке слоя услуг СПП, таких как управление приложения, данные приложения, пользователи, данные пользователей, оконечное оборудование и т. д.
Функция управления транспортным ресурсом предоставляет функциональную возможность для традиционных функций управления транспортом,
с расширением для обеспечения поддержки транспортного слоя СПП, таких
как возможность установления сквозного соединения IP и
управление QoS, и т.д. Пример соответствующих видов ответственности
функции управления обслуживанием и функции управления ресурсами приведен далее. Предоставление заданного обслуживания конечным пользователям приведет к созданию в функции управления обслуживанием нового экземпляра услуги, которое свяжет результаты распределения требуемых ресурсов обслуживания и транспортных ресурсов для этого экземпляра услуги
с помощью функции управления ресурсами.
Взаимодействие с функцией управления транспортным ресурсом осуществляется:
 для проверки наличия требуемых ресурсов транспортной сети;
 для сквозной/общей для всех приложений конфигурации требуемых
ресурсов транспортной сети;
 для конфигурирования линии доступа этого конечного пользователя в соответствии с техническими требованиями, соответствующими договору об обслуживании.
Взаимодействие с функцией управления ресурсом обслуживания осуществляется :
 для создания всех данных пользователя и соответствующей сетевой
базе данных в случае нового пользователя;
 для создания в соответствующей сетевой базе данных всех относящихся к обслуживанию данных для этого пользователя;
 для распределения требуемых ресурсов сети обслуживания;
 для срабатывания/проверки конфигурации оборудования в помещении пользователя (CPE).
Управление и операции в области ресурсов отвечает за управление
ресурсами в слое услуг сетей.
Управления и операции в области обслуживания подразделяются на
функции управления сетью обслуживания и функции управления элементами
118
обслуживания. Инфраструктура слоя услуг сети включает в себя данные/информацию, требуемые для обеспечения функционирования услуг сети
с:
 связанными механизмами, используемыми услугами для доступа к
данным;
 управлением содержащимися данными.
Функция управления ресурсом обслуживания включает, но не ограничиваясь этим, следующие функции:
 отображение требований функции управления обслуживанием в
профили обслуживания и данные, интерпретируемые лежащими
ниже ресурсами;
 управление прикладным программным обеспечением и данными
приложения в сети, включая представление, обновление, инвентаризацию, распространение, прикладные технологии, открытые интерфейсы приложения и связанные с ними механизмы обеспечения
 безопасности;
 управление действиями конечного пользователя в отношении его/ее
профиля обслуживания, в том числе : доступ конечного пользователя к его/ее профилю обслуживания, воздействием на систему; отслеживанием изменений профиля, вносимых конечным пользователем; присутствие, расположение, и их воздействием на действующие услуги с точки зрения пользователя;
 управление аспектами, относящимся к возможностям сетей, такими
как выставление счетов, маршрутизация;
 управление механизмами поддержки подписки на услуги и управление подпиской со
 стороны конечного пользователя (самоуправление);
 управление данными абонента, а также базой данных профилей и ее
содержимым;
 набор данных СУО о предоставлении услуг (данные для расчета
времени, необходимый для предоставления услуги пользователю
после подписки), гарантирующий, что услуги
 предоставляются с требуемыми характеристиками;
 набор данных о рабочих характеристиках обслуживания и результатах их анализа, для
 обеспечения подачи на вход функций планирования ресурсов обслуживания;
 управление программным обеспечением, требуемым для услуги, и
конфигурацией
 оборудования в помещении пользователя;
 управление системой, позволяющей осуществлять управление оборудованием в помещении пользователя;
 управление предварительным тестированием обслуживания;
119
 управление правилами избыточности приложений;
 управление переопределением масштабов инфраструктуры в случае, когда требуется
расширить обслуживание;
 управление набором данных о рабочих характеристиках приложения.
Функция управления транспортным ресурсом отвечает за реализацию возможности установления соединения и за конфигурацию других аспектов в сети, относящихся к обслуживанию. В нее входят такие функции,
как выбор технологий сети, маршрутизация, управление сетевыми ресурсами, инвентаризация и т. д.
Функция управления транспортным ресурсом подразделяется на функции управления транспортной сетью и функции управления транспортным
элементом. Она также определяет дополнительные функции управления
СПП для обработки сквозных аспектов реализации транспортных услуг на
сети, таких как:
 отображение требований функции управления обслуживанием в
профили обслуживания, интерпретируемые лежащими ниже уровня
управления сетью;
 управление аспектами установления соединения, относящимися к
возможности
установления соединения на межоператорском
уровне или на множестве сетей, принимая во внимание ситуацию,
характеризующуюся наличием многих поставщиков оборудования,
в которой будут работать сети;
 управление сетевыми ресурсами (например, конфигурацией управления допуском, механизмами QoS, отображениями на границах
между сетями);
 управление аспектами установления соединения, относящимися к
предоставлению ресурсов, связанных с линиями доступа;
 управление сетевыми ресурсами на сети, такими как механизмы
QoS и отображения на
 границах между сетями, конфигурация ТСА/брандмауэра, конфигурация сети сигнализации.
Уровень управления взаимодействием с поставщиками/партнерами отвечает за связь с поставщиками и партнерами с целью привлечения внешних
транспортных ресурсов или ресурсов обслуживания для использования предприятием. Уровень управления взаимодействием с поставщиками/партнерами предоставляет функции обслуживания и поддержки, которые
требуются для поддержки процессов/услуг поставок поставщика, которые
подлежат управлению.
Несмотря на то, что блок функции управления обычно взаимодействует
с блоками функции управления на смежных логических уровнях управления,
по соображениям операционного и
120
управленческого характера может возникнуть необходимость взаимодействий между несмежными
уровнями. Например, по соображениям, связанным с трафиком управления,
уровню управления
обслуживанием возможно понадобится.
5.3 Контрольные вопросы к разделу 5
1.
2.
3.
4.
5.
6.
Что такое «процесс»?
Какие описания включает документы по eTOM?
Какие горизонтальные уровни управления включает карта eTOM?
Что включает процесс «Обеспечение ресурсов»?
Для чего необходимо управлять техническим учетом ресурсов?
Для чего предназначен горизонтальный уровень управления взаимоотношениями с клиентами?
7. Что включает функция управления транспортным ресурсом?
121
РАЗДЕЛ 6. СИСТЕМЫ УПРАВЛЕНИЯ
ТЕЛЕКОММУНИКАЦИЯМИ OSS И BSS
6.1 Понятие о системе OSS оператора связи
Начиная с 1980-х годов, операторы связи повсеместно стали создавать
и применять комплексные автоматизированные системы управления сетями
связи. В настоящее время эти работы проводятся в рамках создания системы
эксплуатационной поддержки (Operation Support System, OSS) оператора связи. Понятие «система эксплуатационной поддержки» ранее использовалось
только в отношении поставщиков оборудования электросвязи на территорию Российской Федерации в части их деятельности по поддержке эксплуатации поставляемого оборудования. Система эксплуатации, согласно ГОСТ
25866-83, определяется как «Совокупность изделий, средств эксплуатации,
исполнителей и устанавливающей правила их взаимодействия документации,
необходимых и достаточных для выполнения задач эксплуатации».
Под «системой эксплуатационной поддержки, OSS» понимается базовое понятие для обозначения набора функций управления, которые применяются оператором связи для мониторинга, анализа и управления системами,
ресурсами и услугами.
Понятие OSS переводится как «система поддержки и эксплуатации сетей для оператора связи». Однако упоминание только сетей без услуг связи
представляется определённым занижением декларированного международными организациями уровня функциональности OSS. В результате, систему
OSS оператора связи в рамках действующих нормативно-правовых актов
можно рассматривать как отраслевую автоматизированную систему управления информационно–телекоммуникационными сетями и услугами связи.
Также система OSS функционирует как информационная система, т.е. представляет собой «…совокупность содержащейся в базах данных информации
и обеспечивающих ее обработку информационных технологий и технических
средств» согласно ст. 2 Федерального закона от 27.07.2006 №149-ФЗ «Об
информации, информатизации и о защите информации». Поэтому система
OSS может рассматриваться как автоматизированная информационная система, что соответствует тенденциям развития информатики и управления в
телекоммуникациях. Система OSS реализует поддержку процессов плана
улучшенной эксплуатации электросвязи eTOM. Для такой поддержки система OSS включает в свой состав готовый программный продукт (продукты) и
комплекс технических средств, в совокупности обеспечивающие функционирование процессов eTOM.
Итак, в самом широком смысле под OSS понимаются все автоматизированные/информационные системы, необходимые для обеспечения основного производства оператора связи – процесса предоставления услуг и
управления сетевыми средствами.
122
В настоящее время российские операторы связи в рамках OSS внедряют преимущественно системы мониторинга, управления последствиями
отказов, системы технического учёта и системы управления IP-трафиком.
Применяются единые продуктовые каталоги.
Зарубежные операторы связи преимущественно внедряют системы
управления услугами, управление доступом и идентификацией пользователей, геоинформационные системы.
С точки зрения схем организации системы OSS, возможны варианты,
представленные на рис. 6.1.
OSS В
OSS Б
OSS А
OSS А
Централизованная
OSS
Условные обозначения :
OSS Б OSS В
Одноуровневые
OSS
Система O S S
OSS А
Иерархическая O S S
Управляемые объекты
Рис. 6.1 - Варианты схемы организации OSS оператора связи
Анализ схем организации OSS на рис. 6.1 показывает, что централизованная схема является самой простой и предназначена для реализации системы поддержки эксплуатационной деятельности на географически ограниченной территории деятельности оператора, например, в пределах одного города
или региона.
Одноуровневая схема организации может использоваться при взаимодействии нескольких OSS (центров управления сетями и услугами), в том
числе и на территории одного региона. При этом системы OSS могут быть
реализованы на основе продуктов различных поставщиков.
Иерархическая схема организации OSS применяется для управления
крупными, территориальнораспределёнными, в том числе национальными
сетями связи, когда необходимо организовать управление между
территориально–разнесёнными и многофункциональными комплексами
связи, в том числе интегрировать систему OSS и систему управления
бизнесом оператора связи (BSS, Business support system). Взаимодействие с
системой BSS также организуется для централизованной и одноуровневой
OSS.
123
Задачи администрирования и управления множеством услуг связи и
инфраструктуры, на которой базируются услуги, являются важнейшими для
оператора связи. Для успешного решения этих задач необходимы специалисты с высоким уровнем технической и психологической подготовки, эффективное применение информационных технологий, оптимальная с точки зрения соотношения затрат/эффективность организация бизнеспроцессов. Все
перечисленные факторы в конечном счёте влияют на бизнес оператора, причём динамически, что обусловлено постоянной конкуренцией на рынке телекоммуникаций и появлением новых технологий и услуг связи. Соответственно OSS призвана в комплексе решать задачи автоматизации и информатизации бизнеспроцессов оператора связи, связанных с предоставлением, обеспечением и расчётом за услуги связи.
Основными техническими факторами, которые оказывают влияние на
состав, функциональность и архитектуру OSS, являются:
 сетевая инфраструктура, которая представлена различными сетевыми технологиями (DWDM, SDH, ATM, Ethernet) и оборудованием различных производителей, где часть сетевых ресурсов может
быть арендована другим оператором;
 типы вычислительных платформ, на базе которых пользователю
предлагаются дополнительные услуги связи, например, хостинг,
электронная почта, поддержка IPтелефонии, сервисные телефонные карты. ЭВМ и установленное на них программное обеспечение
в процессе оказания услуги взаимодействуют между собой, создавая тем самым сеть услуг электросвязи (service network);
 повсеместное наличие управления (менеджера) сетевыми элементами  единого или различного  для оборудования связи и вычислительных платформ. Менеджер элементов сети используется для
установки, конфигурации, мониторинга (состояние и производительность), обслуживания, проверки оборудования систем связи.
Набор функций, необходимый OSS, например, с учётом конкуренции
компаний на рынке услуг местной связи выглядит следующим образом:
Работа с потенциальными пользователями:
 поддержка данных о потенциальных клиентах;
 проверка правильности адресов потенциальных клиентов;
 поддержка доступности услуг связи;
 поддержка специальных цен (маркетинговые компании);
 доступность отдельных компонентов элементов сети (например,
наличие свободной номерной ёмкости или свободных портов).
Предоставление услуги:
 оформление заказа/договора на услуг связи;
 внесение изменений и / или отмена договора;
 обновление информации о пользователях;
 аварийное или экстренное восстановление услуг и данных о поль124
зователях.
Обеспечение услуги:
 поддержка заданного состояния услуги;
 изменение параметров услуги и оборудования связи, например со
стороны пользователя.
Техническая поддержка и восстановление сети:
 поддержка создания, модификации и отмены сообщений о неисправностях;
 запросы на тесты и проверки сетевого оборудования;
 автоматическая передача пользователю уведомлений о неисправностях.
Расчёты за услуги связи (биллинг):
 обработка запросов пользователей и коррекция данных клиентов;
 поддержка данных об интенсивности использования оборудования
связи;
 периодическая подготовка счетов на оплату услуг связи;
 разделение статей оплат по согласованию клиентов;
 информация о несанкционированном пользовании услугами связи.
В целом структура современной OSS по данным компании Telcordia
выглядит так, как на рис. 6.1.
Графический
интерфейс
пользователя OSS
OSS другого
оператора
Открытые
интерфейсы
API
Биллинг
и CRM
Обеспечение
услуги
Управление
сетью
связи
Управление
персоналом
Будущие
приложения
Открытый доступ к общедостпным данным и информационное взаимодействие
между приложениями
Общедоступные
компоненты/
данные SID
Уровень адаптации систем управления элементами
Протокол 1
Протокол 2
Протокол 3
Системы
управления
элементами ТФОП, ISDN IP-оборудование
ATM, Ethernet
Протокол 4
SDH, DWDM
Протокол 5
ОКС№7
Рис. 6.1 – Структура современной OSS
Принципиальным элементом в рассматриваемой структуре является
наличие уровня адаптации систем управления элементами. Это уровень является своего рода шлюзом, который преобразует форматы протоколов управления (CMIP, SNMP, HTTP) в единую форму, данные которой доступны приложениям OSS и могут храниться и обрабатываться в базе данных. Таким
125
образом, имеет место вертикальная интеграция прикладных задач управления и управляемых ресурсов. Эта интеграция соответствует как классической
концепции TMN, так и направлению работ TMF, и, что вероятно самое главное, позволяет объединять программные продукты различного назначения.
6.2 Воздействие OSS на услуги связи
Воздействие OSS на процесс предоставления услуги связи является
скорее эволюционным, чем революционным, что демонстрирует табл. 6.1.
Таблица 6.1 – Функциональность системы OSS
Функциональность OSS
Задачи
оператора связи
Взаимоотношения с пользователем
Управление профилем
услуг
пользователя
Управление привлечением клиентов
Проверка
доступности телекоммуникационных ресурсов
Управление планом
нумерации
Управление
персоналом
Включение (активизация)/ выключение услуг
связи
Взаимо- Предо
действие ставс пользо- ление
вателем и услуг
сервиссвязи
провайдером
+++
Обеспечение
услуг
связи
+
Расчёты
за
услуги
связи
(биллинг)
Уровень
транс
портной
сети
Упра Упра
вле- вление
ние
персесотью
насвялом
зи
++
+
+++
+
+
++
+
+
+
+
+
++
++
++
126
+
+
+
Условные обозначения :
+++ сильное воздействие OSS ++ среднее воздействие + слабое воздействие
Помимо вертикальной интеграции, приложениям OSS необходимо обмениваться информацией между собой и с базой общедоступных сведений.
Это позволяет поддерживать информационное единство системы и, в конечном счёте, обеспечивать управляемость OSS. Для обеспечения такого обмена
в настоящее время ETSI предлагает использовать концепцию шины сообщений (message bus). Основная задача шины  поддержка обмена сообщениями
и данными между компонентами (подсистемами) OSS, которые подключены
к базе. Этот подход позволяет обеспечить интеграцию подсистем OSS только
с шиной, а не с каждым приложением в отдельности. Архитектура данного
решения приведена на рис. 6.3.
Функции шины сообщений состоят в следующем:
 поддержка распределенных приложений;
 гарантированная доставка сообщения адресату. Например, если
данное приложение было временно недоступно, то шина должна
распространить сообщение о восстановлении приложения;
 поддержка информационных технологий взаимодействия приложений типа клиентсервер (запрос  ответ);
 дополнительная функциональность, связанная с обеспечением информационной безопасности, поддержкой транзакций.
В целом шина сообщений рассматривается как средство промежуточного уровня и реализуется продуктами соответствующего класса, который
называют классом интеграции промышленных приложений (Enterprise
Application Integration, EAI). Среди таких стандартов можно привести следующие: CORBA, TIBCO (используется компанией Hewlett-Packard), Kabira,
Corus.
Для того, что бы организовать присоединение приложений к шине сообщений, необходимо использовать адаптер, или блок адаптации (adaptation
unit). В функции такого адаптера входит не только согласование протоколов
управления, но и обмен данными между различными интерфейсами API, что
было показано на рис. 6.3.
Для шины сообщений принципиально важно согласовать содержание и
структуру сообщений, которыми обмениваются подключенные к ней компоненты. Здесь целесообразно применять метки, или теги (tag), известные по
описанию форматов ASN.1. Тег описывает, какой тип данных передаётся, и
ставится перед каждым полем данных.
127
Продажа
услуг
Обработка
заказов
Планирование и
разработка
услуги
Обработка
проблем
Конфигурация услуги
Ш ина
Планирование и
развитие
сетей
Обеспечение
сетей для их
функционирования
Управление
элементом
сети 1
Управление QoS
пользователя
Разреш ение
проблем с
услугами
Выставление счетов
и сбор оплат
У правление
качеством
услуги
Н ачисления и
скидки на
оплату услуг
сообщ ений
У правление
техническим
учётом
Управление
элементом
сети 2
...
Эксплуатация
и восстановление сетей
Управление
данными
сети
Управление
элементом
сети n
Рис. 6.3 – Информационное взаимодействие компонентов OSS c
использованием шины сообщений (по данным ETSI)
Это механизм позволяет поддерживать целостность системы даже в
том случае, если схема данных изменяется и необходимо обновить те приложения OSS, которые работают с изменёнными данными. При этом прочие
приложения OSS не обновляются, так как работают со «своими» данными,
получаемыми из полей сообщений, которые не были изменены. В настоящее
время для такого описания данных, точнее говоря самоописания, широко используется язык XML.
В настоящее время речь идёт не только об обмене данными, но об обмене информационными объектами в рамках общих информационных моделей. Общая информационная модель бизнес-объектов (common business
object model) получается путём конвертации оригинального сообщения в общую информационную модель, после чего сообщение посылается или публикуется на шине. Конвертация сообщения осуществляется блоком адаптации или специальной функцией конвертации промежуточного обеспечения.
Шина сообщений, общая информационная модель и управление последовательностью выполняемых действия (workflow engine) являются базовыми позициями в рамках новой инициативы TN Forum «OSS сетей связи
следующего поколения» (New generation OSS, NGOSS).
NGOSS является официально зарегистрированной торговой маркой.
Проект NGOSS, работы по которому ведутся с 2000 г., включает разработку
бизнесподходов к применению, разработку требований и принципов построения компонентов приложений и инфраструктуры. При этом инфраструктура NGOSS разрабатывается как нейтральная, т.е. с ней смогут взаимодействовать специфические информационные технологии. Работы по проекту NGOSS сопровождаются разработкой спецификаций контрактов (о контрактах см. выше). Схема TOM выступает при этом как схема процессов, которые будут поддерживаться NGOSS.
128
Следует сказать несколько слов о стоимостных показателях внедрения
OSS. Стоимость полномасштабного проекта внедрения OSS в том виде, как
это представлено на рис. 6.1, составляет от 5 до 20 миллионов долларов
США. Внедрение OSS становится первоочередной задачей всего персонала
компании связи  от руководителей высшего звена до эксплуатационного
персонала и инженернотехнического состава.
Если учесть, что от 60% до 70% процентов расходов оператора приходится на сетевые процессы, то OSS позволяет осуществлять эти процессы
быстрее и дешевле. Следовательно, наличие масштабной OSS у оператора
связи может иметь решающее преимущество в конкурентной борьбе.
Отдельно стоит остановиться на вопросе поставщиков OSS. Существует две основные группы  большинство производителей телекоммуникационного оборудования и некоторые из крупных независимых поставщиков
OSS, претендующих на наличие полной линейки решений OSS. Тем не менее, обе группы поставщиков часто адаптируют свои решения под конкретный бизнес оператора. Для оператора, который работает на достаточно узком
секторе рынка (например, только IPтелефония или только DSLдоступ) и не
намерен расширять свой бизнес в другие рыночные сегменты, может использоваться «коробочное» решение OSS. Как правило, «коробочное» решение
не требует долгого внедрения и позволяет избегать существенных трудностей, связанных с системной интеграцией. Разумеется у подобного подхода
имеются и существенные недостатки:
 зависимость от единственного поставщика  известно, что не существует поставщика, который был бы хорош всегда;
 гибкость системы  не всегда ясно, что произойдёт, если потребуется иметь дополнительные возможности OSS в случае расширения
сферы бизнеса или предоставления новых услуг связи;
 поддержка оборудования многих производителей  не исключено,
что при «коробочном» решении возможности поддержки оборудования от различных производителей будут ограничены.
По данным компании JP Morgan Securities Inc, наиболее развитыми в
функциональном плане являются три функциональных компонента OSS: взаимодействие с пользователем и биллинг; управление заказами/запросами
услуг связи и предоставление услуги; управление сетевыми операциями, т.е.
управление сетью.
Российские операторы связи также внедряют OSS. При этом российский вариант OSS, как правило, строится на основе продуктов как поставщиков телекоммуникационного оборудования (управление элементами сети и,
реже, управление сетями связи), так и продуктов независимых поставщиков
OSS. В последнем случае операторам связи поставляются прежде всего биллинговые системы, которые становятся основой для построения современных
систем BSS/OSS.
Таким образом, российский вариант OSS  это многокомпонентная система, для которой принципиально важным является наличие открытых ин129
терфейсов для информационного взаимодействия. В настоящее время проводятся работы по выработке корпоративных стандартов информационного
взаимодействия компонентов OSS.
6.3 Развитие систем сетевого управления
Одной из главных причин развития систем и платформ управления в
последние годы является постоянная конкуренция в сфере телекоммуникаций. Причём конкуренция идёт не на уровне телекоммуникационного оборудования – парк технических средств связи практически одинаков у конкурирующих операторов или сервис-провайдеров. В условиях конкурентной
борьбы и развития рынков новых и базовых услуг связи на передний план
выходит обеспечение гарантированного качества услуг связи. Решение этой
задачи требует от оператора как вертикальной так и горизонтальной интеграции имеющейся телекоммуникационной инфраструктуры. Если требуется
обеспечить качество услуги по принципу «из конца в конец», то здесь необходимо осуществлять не только технический контроль и управление элементами сети и сетью связи, но и постоянно сравнивать получаемые статистические данные с условиями соглашения об уровне обслуживания SLA, заключенного с пользователем. В этом случае серьёзное влияние приобретают технологические процедуры и мероприятия по обеспечению гарантии качества
услуг (Service Assurance).
В части оптимизации бизнес-процессов операторов и сервиспровайдеров, появились не только средства управления бизнесом, но, в
первую очередь, новые методы исследования и моделирования бизнеспроцессов как на содержательном уровне (уровень описания), так и на уровне
реализации. Продолжается совершенствование средств и методов анализа/синтеза технологических цепочек производственных процессов с целью
снижения эксплуатационных затрат на предоставление услуг связи и повышения эффективности использование оборудования.
На нижних уровнях управления (управление элементами сети и управление сетью) происходит дальнейшее развитие систем управления «от производителей». Это неизбежный процесс т.к. никто лучше производителя не
знает особенностей конструкции выпускаемого оборудования. Проблема состоит в том, чтобы в программном обеспечении управления систем и оборудования связи были предусмотрены стандартные интерфейсы управления Q и
необходимые средства для создания MIB. Причём функции управления и
протоколы управления, доступные с помощью интерфейса Q, должны быть
одинаковы для различных систем управления. В противном случае существенно возрастают затраты на создание интегрированной системы управления сетью и услугами. В этой связи для семи межрегиональных компаний
связи (МРК) и ОАО «Ростелеком» актуальной является задача создание интегрированной («зонтичной») системы управления транспортной сетью SDH
130
(рис. 10.4), которая будет взаимодействовать с «фирменными» системами
управления сетью и/или сетевыми элементами, развернутыми на территории
филиалов МРК.
Особое значение приобретают методы интеграции управления различными вилами связи. Принципиальной задачей является унификация информации управления внутри системы.
В системе управления существуют самые разнообразные данные –
сведения об объёме переданной/принятой информации, сведения о продолжительности сеансов связи, которые далее используются для расчётов за
услуги связи, многообразная технологическая информация. Необходимо
привести описанные данные к единой форме представления так, чтобы при
расчёте за услуги связи принималось во внимание не только фактическое
время пользования услугой но и состояние технических средств в момент
пользования услугой, т.е. учёт качества услуги связи. Это особенно важно
для систем IP-телефонии, других телематических служб.
Важным является направление, связанное с делегированием т.е. предоставлением части полномочий по управлению услугами (а в перспективе и
оборудованием связи) конечному пользователю.
Эти мероприятия позволяют разгрузить оператора от многих рутинных
функций по управлению, обеспечивают источник доходов от предоставления принципиально новых услуг, например предоставление средств администрирования профиля услуг клиента, платный доступ к подробным сведениям о состоянии лицевого счёта пользователя. В этом случае необходимо чётко разграничить доступ к информации управления, обеспечить информационную безопасность доступа.
Особое место применительно к решению задач управления услугами и
сетями связи занимает развитие новых информационных технологий. Если
принять за основу продолжающееся развитие технологий промежуточного
уровня (middleware), то перспективные программные приложения управления будут поддерживать распределённую обработку информации управления. Это потребует надёжных сетей для обмена данными и приведёт к применению децентрализованной схемы обработки данных при сохранении
принципов централизованного управления.
В результате использование новых технологий может привести к
уменьшению числа уровней управления. Не исключено, что на начальном
этапе развёртывания современной системы сетевого управления, центры
управления будут создаваться по видам сетей связи (ЦУ сети передачи и ЦУ
коммутируемой сеть), а с течением времени эти центры будут преобразованы
в центры объединённого управления сетями электросвязи.
131
Уровень
федеральной
(межрегиональной)
компании связи
Интегрированная
NMS
N-OS
Сеть передачи данных DCN
Региональный
уровень
N-OS
ЭС
ЭС
ЭС
ЭС
...
N-OS
E-OS
Местные
сети
ЛВС
ЭС
EMS
SNMS
SNMS
ЭС
ЭС
ЭС
ЭС
ЭС
ЭС
ЭС
ЭС
ЭС
ЭС
Условные обозначения :
E-OS - операционная система управления элементом сети (element operation system)
N-OS - операционная система управления сетью (network operation system)
SNMS - система управления подсетью (subnetwork management system)
EMS - система управления элементом или элементами сети (element management system)
Рис. 10.4 – Интегрированная система управления транспортной сетью
SDH для МРК (по данным ЦНИИС, ЛОНИИС)
Платформа распределенного управления компании Hewlett-Packard
(HP) OpenView Telecom Distributed Management (DM) TMN  это программная платформа, на которой строятся переносимые системы управления для
телекоммуникаций, удовлетворяющие открытым стандартам. Работы по данной системе были начаты в 1985 г. В 2000 г. платформа переименована в
OpenView Communications/Service Assurance (HP OVC/SA), причём функциональные возможности управления были расширены с учётом необходимости
поддержания заданного качества услуг пользователя в гетерогенных сетях .
При разработке HP OpenView Telecom DM TMN особое внимание уделялось требованиям производителей оборудования, поставщиков услуг и
компаний системных интеграторов к надежности, производительности и
возможности распределенного функционирования. Компоненты HP
OpenView Telecom DM TMN удовлетворяют спецификациям протоколов,
объектов и услуг, определенных МСЭТ, ISO и IETF в части SNMP. Обеспечивается полная поддержка протоколов сетевого управления CMIP и SNMP.
Платформа HP OpenView Telecom DM TMN построена в соответствии с
принципами архитектуры открытых систем, позволяющей получать аппарат132
но-независимые решения. Поддержка обеспечивается для рабочих станций и
серверов HP типа 9000, работающих с операционной системой HP-UX версий
10.20, 11.0 и выше, а также рабочих станций Sun SPARC с операционной системой Solaris 2.6, 7, 8 и выше. Допускается применение компьютерных
средств на базе микропроцессоров производства компании Intel с операционными системами MS Windows NT версия 4.0 и MS Windows 2000.
Платформа HP OpenView Telecom DM TMN предоставляет набор
служб, которые могут использоваться для управления обработкой событий и
сообщений от сетевых элементов и систем. Этот набор включает посредническую службу, которая осуществляет сбор, сохранение, фильтрацию и разбор сообщений, а также службу управления обработкой событий, отображающую и коррелирующую взаимосвязанные события и активизирующую
внешние приложения на основе данных об аварийных ситуациях.
Платформа HP OpenView Communications (ранее – Telecom) DM TMN
включает два базовых продукта :
Платформа DM TMN Agent – включает необходимую коммуникационную инфраструктуру (аппаратно-программное обеспечение), которое позволяет осуществлять маршрутизацию сообщений, оказывать услуги автоматического контроля информационного обмена между приложениями управления, предоставлять услуги регистрации объектов в базе данных агента и
услуги обработки событий. Эта же платформа позволяет осуществлять развёртывание программы-агента для элементов сети или разработку приложений управления с графическим интерфейсом пользователя.
Платформа DM TMN Manager – объединяет платформу сетевого менеджера и инструменты разработчика менеджеров (Manager’s Develloper’s
Kit). Эта составляющая платформы сетевого управления включает DM TMN
Agent вместе с продуктом Network Node Manager. Платформа DM TMN Manager поддерживает разработку сетевых менеджеров и комбинированных приложений менеджерагент. Имеется графический интерфейс с поддержкой
географических карт OpenView Windows GUI.
Продукт Network Node Manager [Менеджер сетевых узлов] обеспечивает интеллектуальное, ориентированное на пользователя управление сетевого
окружения для провайдеров услуг сети Интернет, пользователей услуг аутсорсинга (outsourcing) и провайдеров услуг связи в промышленном масштабе
(Enterprise service providers). Согласно рекламным материалам компании
Hewlett-Packard, решения HP OpenView Network Node Manager в настоящий
момент являются «краеугольным камнем» семейства HP OpenView и основой
для разработки решений третьей стороной на базе Network Node Manager.
Продукт Network Node Manager поддерживает централизованной хранилище данных системы и обработку данных управления, что позволяет администраторам сетей выполнять сложный анализ тенденций развития сетевой ситуации. При этом используется технология интеллектуальной корреляции событий (event correlation technology), позволяющая устанавливать
взаимосвязь между сигналами о неисправности или отказе. В результате ад133
министратору сети с помощью функции маршрутизации поступает единый
высокоуровневый сигнал о главном источнике возникшего сбоя. Данный
продукт позволяет автоматически создавать и поддерживать карту TCP/IP и
IPX сетей, поддерживается «тонкий» клиент на основе Java и WEBинтерфейс пользователя.
Графический пользовательский интерфейс GUI обеспечивает сетевых
операторов и администраторов HP OpenView согласованным представлением
управляемой среды и интеграцией функций управления, независимо от поставщика или типа управляемого объекта. Многоконный интерфейс HP
OpenView предоставляет общий интерфейс, упрощающий разработку и использование административных приложений.
Общую схему платформы HP OpenView Telecom DM TMN см на рис.
10.2.
HP OpenView Windows
Менеджер
Средство
разработки
объектов
(Managed
Object Toolkit)
Агент
API
Маршрутизация
ACSE
соединения
Средство
разработки
GDMO
Программа обработки
(постобработки)
данных управления
CMIP
GDMO
специфик
ации
Услуги
обработки
событий
SNMP
Рис. 10.2 – Основные компоненты платформы HP OpenView Telecom
На рис. 10.2 программа обработки (постобработки) данных управления
вместе с программами маршрутизации и услугами обработки событий выполняет распределенную маршрутизацию сообщений, в первую очередь сообщений о неисправностях и предоставляет доступ к приложениям управления через API. Эта же программа осуществляет интеграцию протоколов
управления CMIP и SNMP в единую систему управления. Доступ пользователя к системе осуществляется через графический интерфейс HP OpenView
Windows.Средство разработки описания объектов (Managed Object Toolkit) на
основе спецификаций GDMO и средств разработки GDMO позволяет созда134
вать описание управляемых объектов и реализовывать это описание в виде
j,]trnjd баз данных управления.
Решения по интегрированному управлению услугами связи предлагаются компанией Hewlett-Packard в виде компонента HP ISM (Integrated Service Management). Основные компоненты HP ISM:
 Компонент HP OpenView – позволяет отслеживать и контролировать ресурсы и телекоммуникационную инфраструктуру, а также
управлять ими.
 Компонент HP Process Manager – предоставляет возможность оперативно определять, отслеживать и детализировать операционные/сетевые процессы на всем протяжении жизненного цикла
услуг.
 Компонент HP Internet Usage Manager – предоставляет возможности
для биллинга т.е. расчётов за услуги связи, реализуемые с помощью
информации об использовании услуг.
В составе HP ISM применяется несколько программных продуктов. В
частности, продукт HP Service Delivery позволяет быстро, эффективно и с
минимальными затратами выпустить на рынок новые услуги связи. HP Service Delivery управляет процессом ввода в эксплуатацию услуг, а также осуществляет контроль за ходом их предоставления.
Контроль обеспечения качества обслуживания осуществляется с помощью продукта HP Service Assurance. Этот продукт управляет соглашениями об уровне обслуживания SLA и поддерживает для предоставляемых
услуг такой уровень качества, который установлен для клиентов согласно
SLA. Это решение позволяет управлять всеми компонентами, составляющими процесс проверки качества обслуживания : управление последствиями отказов, создание нарядов на выполнение работ и управление производительностью/техническими характеристиками сети. С помощью HP Service Assurance можно обеспечить высокое качество обслуживания и добиться oneративного разрешения проблем при минимальном времени простоя сети электросвязи.
В составе набора продуктов для управления услугами имеются решения по управлению услугами IPтелефонии. Основные компоненты решений
HP для управления услугами IP-телефонии нового поколения выглядят следующим образом:
 платформа HP OpenCall  программное средство организации сеансов,
контроля услуг и оборудования IPтелефонии;
 программные коммутаторы Softswitch, шлюзов и серверов приложений
от партнеров Hewlett-Packard;
 интегрированное управление услугами HP VoIP (voice over IP, голос по
сетям IP);
 серверы и устройства хранения данных HP, оптимизированные для работы у операторов связи.
135
Помимо управления услугами проводных средств связи, в составе HP
ISM имеется ряд продуктов для управления услугами подвижных сетей связи.
По утверждению компании Hewlett-Packard, 67% американских компаний, провайдеров Интернет-услуг используют программное обеспечение HP
Open View. В настоящее время объединённое решение HP Open View TeMIP
solutions применяется на 170 телекоммуникационных сетях, в том числе на 8
крупнейших международных сетях из 10 (по рекламным данным). Лицензиями на право использования этой платформы OpenView DM Telecom TMN обладают ведущие зарубежные компании Siemens, Alcatel, Nortel, Lucent, Nokia,
Fujitsu. Платформа HP Open View TeMIP интегрирована с продуктами и
устройствами таких фирм, как Motorola, Siemens, Marconi, Tellabs, Ericsson. В
частности, крупнейшая компания British Telecom использует HP Open View
TeMIP в качестве контроллера услуг широкополосной сети для обеспечения
услуг ATM, FrameRelay, ADSL.
В настоящее время компания Hewlett-Packard также предлагает средства HP OpenView ServiceCenter/SLM для управления качеством услуг связи.
Данное приложение позволяет осуществлять мониторинг и генерацию сообщений об услугах в реальном времени.
6.3
Контрольные вопросы к разделу 6
1. Дайте определение понятию «система OSS».
2. При каких условиях целесообразно создавать иерархическую OSS?
3. Из каких компонентов состоит OSS?
4. Как компоненты OSS связываются между собой?
5. Для чего в составе OSS имеется SID?
6. В чём различие между системой и платформой сетевого управления?
7. В чём особенность решения компании Hewlett Packard для управления сетями связи?
8. Каковы основные направления развития систем управления?
136
РАЗДЕЛ 7. ТЕХНИЧЕСКАЯ ЭКСПЛУАТАЦИЯ СЕТЕЙ И
СИСТЕМ СВЯЗИ
7.1 Техническая эксплуатации и измерения на сетях
связи
Техническая эксплуатация сети телекоммуникации – это комплекс
организационных и технических мероприятий по поддержанию работоспособности оборудования сети в состоянии,
обеспечивающем обслуживание абонентов с заданным качеством при
передаче и приеме или любых видов информации, для которых эта сеть
предназначена. Система технической эксплуатации складывается из следующих компонентов:
 аппаратных и программных средств контроля и проверки устройств;
 методов обнаружения и устранения неисправностей, возникающих в
приборах, узлах и линий связи;
 организационных мероприятий, определяющих методы и способы технического обслуживания;
 квалификации и подготовки персонала.
Целью эксплуатации является непрерывная, бесперебойная работа телекоммуникационных сетей и систем связи при их использовании по назначению в любое время. Для достижения поставленной цели необходимо выполнять работы по содержанию оборудования в норме и устранению неисправностей, обеспечения электроснабжения, а также необходимого микроклимата. Все это необходимо выполнять экономично так, чтобы были получены минимальные затраты при капиталовложении.
Техническая эксплуатация сети телекоммуникации включает в себя
техническое обслуживание и ремонт оборудования, а также управление сетью.
Техническая эксплуатация может осуществляться двумя способами:
 централизованно;
 децентрализовано.
При централизованном способе, обслуживание оборудования производится техническим персоналом, сосредоточенным в центре управления сетью, который может находиться на значительном расстоянии от обслуживаемого оборудования.
При децентрализованном способе технической эксплуатации все работы по техническому обслуживанию средств связи проводятся техперсоналом, закрепленным за определенным оборудованием и постоянно находящимся на тех или иных узлах сети связи.
137
Централизованный способ обслуживания наиболее перспективен для
применения на современных сетях связи. Это обусловлено широким распространением оборудованием связи с встроенными средствами автоматического контроля, диагностики и дистанционной передачи и
приема необходимой информации о повреждениях и измерения трафика на
сети.
Основные задачи технической эксплуатации следующие:
 обеспечение бесперебойной, эффективной и высококачественной работы сетей и систем связи;
 поддержание заданных норм качества связи от пользователя до пользователя в пределах данной сети и в международном масштабе в целом;
 совершенствование методов технической эксплуатации, проверок и испытания оборудования, каналов и линий с автоматизацией процесса
обнаружения происходящих повреждений;
 измерение и накопление необходимых статистических данных о трафике, характеризующих состояние узлов и сетей связи, а также отдельных узлов и направлений для управления сетью.
Известно три метода технической эксплуатации, используемых на сетях телекоммуникации:
1. Профилактический.
2. Статистический (контрольно- корректирующий).
3. Восстановительный.
Профилактический метод технической эксплуатации характеризуется тем, что кроме мероприятий по выявлению и устранению техническим
персоналом повреждений, возникающих в процессе работы оборудования,
каналов и линий, проводятся планомерные профилактические проверки оборудования. В профилактическом методе техобслуживание осуществляется до
возникновения отказов оборудования.
Периодичность профилактических мероприятий должна определяться
надежностью оборудования, каналов и линий связи
способом контроля за его состоянием.
Структура профилактического контроля следующая:
 контроль за состоянием оборудования средств связи;
 текущее обслуживание и тестирование аппаратного обеспечения;
 электрическая проверка цепей и контактов;
 тестирование, проверка целостности программного обеспечения;
 проверка информационной безопасности и антивирусная проверка;
 текущий и капитальный ремонт.
Текущее обслуживание заключается в постоянном, круглосуточном
наблюдении технического персонала за работой оборудовании и устройств
электросвязи, в выявлении и устранении повреждений, возникающих в процессе эксплуатации средств электросвязи, а также в наблюдении за содержанием и состоянием оборудования и помещения.
138
Профилактические проверки проводятся по плану с определенной периодичностью в часы наименьшей нагрузки, т.е. после 24.00 ночи до 6.00
утра.
Многолетний опыт применения профилактического метода эксплуатации оборудования показал, что этот метод имеет следующие недостатки:
 профилактические проверки фактически не улучшают состояние оборудования, а лишь выявляют часть имеющихся в данный момент повреждений. При этом отсутствует дифференцированный подход к состоянию оборудования;
 при удовлетворительном состоянии оборудования профилактические
проверки обнаруживают очень мало повреждений, несмотря на большие эксплуатационные расходы;
 не обоснован планово-предупредительный ремонт всего оборудования,
независимо от его состояния;
 ведение профилактических работ приводит к новым дополнительным
повреждениям со стороны самого техперсонала.
 в период проведения профилактических работ и текущего ремонта
часть оборудования выключается, блокируется или снимается, что
снижает качество обслуживания абонентов из-за недостатков каналов,
линий или приборов.
Число повреждений систем связи существенно зависит от качества работы узлов связи, от проработанных лет и т.д. Так, число выявленных повреждений во вновь построенной станции - А значительно ниже, чем станций
проработавшей 20 лет - В.
Статистический метод технической эксплуатации предусматривает
замену профилактических работ постоянным автоматическим контролем за
состоянием основного оборудования каналов и линий, а также за качеством
работы станции, узлов и сети в целом. При статистическом методе применяются методы математической статистики для сбора и обработки данных о состоянии оборудования, что приводит к уменьшению объема необходимых
статистических данных и сокращению затрат рабочего времени на их сбор и
обработку.
Вмешательство технического персонала в работу оборудования и сети
связи допускается только тогда, когда повреждение или перегрузка на сети
вызывает ухудшение качества обслуживания.
Применение данного метода требует выполнения следующих условий:
1. Постоянный сбор статистических материалов о работе различных
средств связи, их трафика и сроков действия.
2. Анализ статистических материалов и сопоставление показателей качества с предельно допустимыми нормативными величинами.
3. Принятия на основе анализа решений о проведении работ по обеспечению требуемого уровня качества, определенного нормативами.
Этот метод не исключает профилактических проверок и измерений, а
лишь ограничивает иx объем. При статистическом контрольно139
корректирующем методе обслуживающий персонал не стремится к полной
ликвидации повреждений. Он стремится при минимальной затрате на обслуживание оборудования, состояния при котором качество связи удовлетворяло
бы норме.
Структура статистического (контрольно-корректирующего) метода
технической эксплуатации представлена на рис. 7.1.
Рис. 7.1. Структура статистического (КК) метода.
Для изучения массовых явлений применяют выборочный метод
наблюдений, т.е. не сплошное наблюдение, при котором обследованию подвергаются не все единицы, а только некоторая их часть.
Особенность выборочного метода следующая:
 характеризовать изучаемое явление на основе обследования части входящих в него единиц;
 иметь возможность провести статистическое изучение с меньшими затратами сил и средств;
 сократить сроки наблюдения и организовать его более тщательно.
Основными характеристиками служат средний размер признака - Х и доля
(удельный вес) признака - Р в изучаемом явлении.
Восстановительный метод эксплуатации характеризуется тем, что
техническое обслуживание производится в момент возникновения отказов.
При этом методе происходит лишь исправление (восстановление) оборудования, на основе поступивших жалоб или сигнализации. При восстановительном методе нет специальных планово-профилактических проверок, которые в том или ином объеме имели место в двух предшествующих методах
технической эксплуатации.
Структура восстановительного метода состоит из двух основных частей:
1. Восстановление оборудования и ремонт по заявкам.
2. Капитальный ремонт или замена оборудованием нового поколения.
140
Наибольшее влияние на систему эксплуатации оказывает основной фактор – технические характеристики системы обслуживаемого узла связи и в
первую очередь, ее надежность.
Восстановительный метод технической эксплуатации исключает профилактические проверки или профилактический осмотр. При этом методе
лишь исправляются и устраняются повреждения, обнаруженные и выявленные:
 согласно заявкам пользователей;
 с помощью сигнализации;
 с помощью ЭВМ технической эксплуатации.
Восстановительный метод требует значительно меньших затрат по
сравнению с профилактическим и статистическими (КК) методами технической эксплуатации. Однако при этом методе эксплуатации, если нет готовых
к замене оборудования и программного обеспечения, зачастую снижается качество обслуживания, т.к. необходимо немедленно устранить или заменить
выявленные повреждения. Иначе они, накапливаясь больше допустимых величин, делают работу оборудования неудовлетворительной. Этот метод
предназначен для оборудования, которое работает безотказно, с заранее заданными потерями в течение определенного времени до предусмотренной
планом его замены, что свойственно современной электронно-цифровой технике.
При наличии аппаратуры автоматического контроля или ЭВМ технической эксплуатации для современных систем телекоммуникации, оборудование и устройства связи находятся под
постоянным, непрерывным наблюдением и контролем, результаты которого
автоматически выдаются на рабочее место оператора, где фиксируются все
выявленные повреждения. Это позволяет своевременно восстановить необходимые устройства, корректировать характеристики не несоответствующие
нормам. Простой оборудования связи при данном методе сведен до минимума, а качество связи улучшается при сокращении расходов на техническую
эксплуатацию.
Применение автоматизированного – программированного контроля
оборудовании средств телекоммуникации в любом случае повышает дисциплину обслуживания.
7.2 Измерения на сетях связи в процессе эксплуатации
Важной составляющей процессов технической эксплуатации является
проведение различного рода измерений на сетях связи.
Измерения основаны прежде всего на процессах анализа параметров
среды распространения сигнала электросвязи и на процессах оценки характеристик сигнала электросвязи при его распространении по физической среде.
Например кабельные эксплуатационные измерения состоят из тестирования
141
электрических (металлических) и оптоволоконных кабелей до их укладки в
кабельную канализацию, в момент укладки и далее в процессе эксплуатации,
в том числе в период устранения последствий отказов или сбоев на сетях связи.
Для электрического кабеля измерения могут осуществляться для определения рабочих или эксплуатационных характеристки структурированных
кабельных линий связи (СКС), для абонентских и магистральных кабелей
связи. Измерения волоконно–оптических линий связи могут проводиться для
сетей PON, объектовых сетей, сетей доступа и транспортных сетей различного уровня.
После измерений физической среды осуществляются измерения и диагностика параметров и характеристик трактов цифровых сетей передачи и
систем аналоговой передачи с ЧРК и ВРК.
Наконец самым сложным уровнем измерений являются измерения, связанные с оценкой качества передачи информации, прежде всего с оценкой
качества передачи речи. В этом случае не всегда возможно применение только аппарату измерений. Например для оценки качества передачи речи – четкости, разборчивости, уровня шума, задержек требуется участие человека/людей которые формируют усредненную среднесубъективную оценку качества передачи речи.
Все перечисленные группы измерений производятся системно и последовательно, согласно действующим нормативно–правовым актам, ГОСТам,
ОСТам, СНИПам, корпоративным стандартам.
Задачами организации измерения являются следующие:
 Проверка соответствия характеристик линий, сетей и систем связи
принятым нормам на момент приемки в опытную или постоянную
эксплуатацию.
 Проверка соответствия характеристик линий, сетей и систем связи
принятым нормам в процессе эксплуатации для выявления несоответствия нормам и предотвращения/предупреждения отказов.
 Определение характера и места повреждения оборудования и линий
связи.
 Проверка качества произведенного ремонта.
Производимые измерения можно разделить на группы :
 Приемо–сдаточные измерения
 Периодические (профилактические, регламентные) измерения
 Измерения для определения места и характера повреждения
 Измерения для оценки качества ремонтных и аварийно–
восстановительных работ.
В итоге, например для электрических кабелей общая схема организации измерений имеет вил на рис. 7.2
142
Рис. 7.2 – Общая схема измерений электрических кабелей
Для электрических кабелей связи измерения проводятся с помощью
постоянного или переменного тока.
С помощью постоянного тока измеряют значения параметров сопротивления, такие как сопротивление изоляции, омическая асимметрия цепи,
электрическая прочность изоляции.
С помощью переменного тока измеряют значения параметров собственного затухания цепи, затухание несогласованности, защищенность цепи
на дальнем конце, емкостная связи и асимметрия, параметры волнового сопротивления,
На этапе эксплуатации для металлических (электрических) кабелей на
транспортных сетях измерения проводятся для:
 Определение места повреждения средствами удаленной диагностики – с помощью мостовой схемы/ измерительного моста или рефлектометра.
 Трассо–поиск т.е. определение места повреждения на местности с
помощью металлоискателя, трассоискателя, маркероискателя, течеискателя.
 Определение параметров кабеля.
 «Прозвонка» кабеля в линейно–аппаратном цехе/на кроссе.
Особое значение имеет измерение электрических кабелей для «последней мили». Например, для оборудования DSL следует проводить обычный анализ параметров кабеля и анализ кабеля с помощью аппаратуры, максимально приближенной к DSL. Для анализа параметров кабеля целесообразно провести измерения:
 Сопротивление шлейфа.
 Комплексный импеданс шлейфа (емкость).
 Сопротивление изоляции.
143




Асимметрия витой пары (нарушение балансировки).
Уровень затухания на полутактовой частоте.
Уровень переходного затухания.
Наличие или отсутствие неоднородностей (некачественные муфты,
параллельные отпайки и т.п.).
Для анализа возможностей передачи тоновых сигналов следует проводить следующие измерения:
 Уровень затухания на полутактовой частоте.
 Неравномерность амплитудно–частотной характеристики.
 Нелинейные искажения
 Фазовый и амплитудный джиттер
 Шум в рабочей полосе частот
 Импульсные помехи и всплески несущей
 Уровень переходного затухания.
Полоса тестирования ADSL может составлять 1 кГц…1500 кГц, полоса
тестирования ADSL2+ составляет 1(1100) кГц … 2200 кГц.
При прокладке волоконно–оптических кабелей связи производятся
следующие группы измерений:
 Рефлектометрия для обнаружения неоднородностей, контроля тракта или участков тракта.
 Сварка волокон и измерения затухания.
 Проверка разговорной связи по волоконно–оптическому кабелю.
 Визуальный анализ состояния коннекторов и оптических интерфейсов (чистота волокна, качество полировки, наличие или отсутствие
сколов, трещин, обломов).
 Монтажные работы с кабелем (вскрытие муфт, разрезание оболочек, разделка кабеля).
Далее, при эксплуатации волоконно–оптических линий связи и оптических систем передачи производятся дополнительные измерения:
 Определение запаса по затуханию в оптической линии (сравнение
реального и расчетного энергетического бюджета оптического сигнала, оценка потенциального запаса по мощности для определения
предельного уровня затухания узла связи)
 Стрессовое тестирование – имитация плохих условий функционирования ВОЛС с целью анализа цифрового канала связи по параметру ошибки (BER). Для имитации помех применяется оптический
аттенюатор, который вносит дополнительное затухание в волокно;
далее определяется зависимость BER от уровня затухания.
 Идентификация активных и пассивных «темных» волокон с помощью идентификаторов активности волокна и без нарушения работы
системы передачи. Здесь проверяется целостность волокна, маркировка кабеля, наличие или отсутствие сигнала перед техническим
обслуживанием. Используется метод некритического изгибания во144
локна, когда часть оптической мощности рассеивается через границу сред.
Например, при использовании волоконно–оптических кабелей связи
для технологии WDM производятся следующие квалификационные измерения:
 Анализ профиля линии с помощью рефлектометра на трех длинах
волн 1310 нм, 1550 нм, 1625 нм в прямом и обратном направлении.
 Измерение потерь на длинах волн 1550 нм и 1625 нм
 Измерение оптических потерь на отражение ORL на длине волны
1550 нм, поскольку высокий уровень ORL может приводить к нестабильности источника излучения и к относительному повышению
ошибок BER приемника.
 Измерение поляризационно–модовой дисперсии PMD, от значения
которой зависит максимально допустимая скорость передачи линии
связи в диапазоне 1550 нм.
 Анализ нелинейных эффектов для оценки возможности использования большого числа длин волн. Два источника излучения настраивают на максимально близкое расстояние между длинами волн; в
результате нелинейного эффектна на ближнем конце наблюдается
два дополнительных пика, мощность и расстояние между которыми
указывают на качество линии связи.
7.3
Особенности
связи
эксплуатации
цифровых
систем
Задачи ТО средств связи :
 предсказать требуемые проверки оборудования и программного
обеспечения;
 определить необходимость, состав и объем измерение необходимых
физических, электрических, акустических и иных параметров работы
сети и сетевого оборудования;
 провести необходимый ремонт для устранения вероятной причины
отказа/повреждения.
Основной задачей при создании перспективных сетей телекоммуникации на базе цифровых систем связи с программным управлением является
значительное снижение эксплуатационных затрат.
Существуют две параллельно решаемые задачи:
1. Обеспечение технической эксплуатации собственно оборудований
станций.
2. Организация технической эксплуатации телекоммуникационных сетей, частично или полностью оборудованных станциями с программным
управлением (ПУ).
145
Оборудования узлов связи с ПУ характеризуются более высокой сложностью и, в целом, могут быть отнесены к классу больших технических систем, в которых выход из строя отдельных элементов не приводит к отказам,
а лишь к некоторому ухудшению или деградации качества функционирования.
Для всех типов средств связи с программным управлением характерны
следующие элементы:
 коммутационная система каналов или пакетов;
 интерфейсное оборудование и устройства сопряжения;
 управляющие устройства (процессоры, контроллеры) различного
назначения ;
 внешние запоминающие устройства (ВЗУ) и т. д.
Как видно из вышеизложенного, характер оборудования узлов связи с
ПУ имеет много общего с вычислительными машинами.
Отсюда вытекают следующие особенности, которые требуется учитывать при эксплуатации узлов связи с программным управлением:
1. Отсутствие движущихся электромеханических деталей, состояние
каждых могло бы быть определено визуально.
2. Обеспечивается высокая надежность оборудования, в том числе путем резервирования.
3. Применяются единые элементная база и технология для построения
различных видов оборудования (устройств коммутации каналов, устройства
коммутации пакетов, устройств управления и систем передачи) и отдельных
функциональных блоков.
4. Используется функциональный принцип компоновки и размещения
оборудования.
Рассмотрим перечисленные особенности, имея ввиду их возможное
влияние на методы и средства обеспечения технической эксплуатации.
Так, отсутствие электромеханических деталей не позволяет визуально
определить состояние оборудования, а следовательно необходимость в проведении большого объема профилактических работ, связанных с периодическим осмотром, чисткой и регулировкой приборов. Напротив, любое вмешательство персонала в работающее оборудование нежелательно, т.к. при этом
появляются неисправности, вносимые персоналом, их количество становится
соизмеримым с неисправностями, возникающими по причине отказа элементов.
Высокая надежность оборудования является главным требованием к
системам коммутации с ПУ. Так, суммарное время полного простоя для
электронных АТС за 20 лет срок службы принято два часа. Среднее время
устранения одной неисправности составляет полчаса, а коэффициент готовности станции в пересчете на одного абонента равен 1,5x10-4.
Новым понятием, по сравнению с электромеханическими системами, является понятие о программной надежности. Программная надежность характеризует долю неисправностей, возникающих за счет ошибок в программах, ко146
торые вы являются в процессе разработки и отладки программного обеспечения (ПО).
Использование единых элементов базы и технологии для построения
различных функциональных блоков как, например, периферийных управляющих устройств (ПУУ), коммутационных
систем (КС), систем передачи (СП) и т. д. приводит к широкой унификации
оборудования АТС с ПУ.
Особенно это характерно для электронных АТС, в которых невозможно различать элементы, используемые в КС, УУ или СП, указанный фактор
наряду с особенностями технической эксплуатации станций с ПУ явился
причиной появления новой базовой конструкции.
Съемным элементом в такой конструкции является плата, именуемая
типовым элементом замены (ТЭЗ). Каждый функциональный блок может
располагаться в одном или нескольких ТЭЗ-ах. Расположение оборудования
в электронной АТС, например, подчинено принципу функционального размещения. Это означает, что на одном стативе или группе стативов размещается оборудование, выполняющее однородные функции (например, стативы
комплектов СЛ, стативы ПУУ, матриц коммутационной системы и т.д.), а
расположение стативов относительно друг друга зависит от степени их
функциональной взаимосвязи.
Большой процент необходимых внутренних соединений между элементами статива обеспечивается за счет межплатного монтажа внутри стативов.
В целом, узлы с ПУ имеют большие возможности для гибкого наращивания и размещения коммутационного оборудования.
Зная техническую основу станций с ПУ можно рассмотреть основные
особенности технической эксплуатации современных цифровых систем коммутации (ЦСК):
1. Оперативно-техническое обслуживание.
2. Эксплуатационное обслуживание.
3. Административное управление.
Целью оперативно-технического обслуживания является поддержание
состояния работоспособности оборудования станции путем непрерывного
наблюдения и оценки результатов контроля, а также замена неисправных
ТЭЗ.
К эксплуатационному обслуживанию относятся функции, не связанные
с поддержанием работоспособности станции. В частности это:
 регламентные работы для получения данных характеризующих работу
узлов связи;
 профилактические работы на отдельных элементах оборудования;
 программно-производственные проверки;
 внесение изменения в эксплуатацию (перекроcсировка, изменение версий программного обеспечения, введение новых видов услуг и т.д.).
147
В рамках эксплуатационного обслуживания выполняются функции в
масштабе сети (переключение каналов, развитие и модернизация оборудования, замена программного обеспечения (ПО), введение новых узлов связи,
введение дополнительных видов обслуживания (ДВО) на уровне сети.
Под административным управлением понимают функции, выполняемые эпизодически и связанные с радикальными изменениями процесса технической эксплуатации, необходимость которых определяется на основе анализа данных о функционировании цифровых систем коммутации с ПУ за длительный период.
Выполнение всех видов систем технической эксплуатации станций с
программным управлением обеспечивается с помощью программноаппаратных средств на рис. 7.3.
Рис. 7.3 – Программно-аппаратные средства системы ТЭ
В качестве аппаратных средств широко применяются внешние устройства ЭВМ:
технической эксплуатации цифровых АТС
 пишущие машины;
 телетайпы;
 экранные пульты (дисплей);
 устройства ввода-вывода информации с промежуточных носителей.
В некоторых случаях используют устройства отображения, реализованные в виде специализированных световых табло.
Перечисленные средства обеспечивают программный доступ к большей части оборудования, что является существенной особенностью АТС с
148
ПУ, Непосредственный (электрический) доступ к оборудованию обеспечивается органами ручного управления и применяется ограниченно для отдельных устройств телефонной периферии.
Устройство ввода-вывода и устройство отображения с необходимыми
органами управления, а также органы управления с непосредственным доступом размещаются на пульте и являются рабочим местом оператора цифровых АТС.
АРМ оператора по технической эксплуатации позволяет обеспечить
функции, предусмотренные в режиме нормальной эксплуатации, исключающим возможность вмешательства персонала в работу управляющего комплекса узла связи. Для технической эксплуатации управляющего комплекса
узла связи в период штатного функционирования, а также в период отладки и
пуска цифровых узлов связи
используются отдельные программно–
аппаратные средства.
Программное обеспечение системы технической эксплуатации цифровых узлов связи включает в себя операционную систему и программы, реализующие выполнение
отдельных эксплуатационных процедур. Задачами операционной системы
является обеспечение
диалога человек–машина и диспетчеризация выполнения всех процедур на
основе отображения состояния и функционирования компонентов узла связи.
В состав средств диалога входят язык оператора MML, реализующий определенные правила составления директив оператора и редактирования выводимых сообщений.
Средства диспетчеризации включают в себя программы, обеспечивающие необходимое взаимодействие между системой технической эксплуатации и другими частями программного
обеспечения цифровых узлов связи (диспетчер системный), а также программы, управляющие выполнение эксплуатационных процедур. Программы
реализации процедур могут запускаться в работу оператором, при этом каждая процедура реализуется одной или несколькими программами.
Помимо перечисленных средств имеются программы контроля и поиска неисправностей в оборудовании и программном обеспечении. Как правило, все эти программы входят в состав системы технической эксплуатации.
Действие оператора современных цифровых узлов связи при обращении к системе с целью реализации какой-либо процедуры заключаются в составлении директивы на дисплее коммутатора
по техобслуживанию. Директива составляется на языке общения «человек–
машина» MML в соответствии с правилами синтаксиса и семантики языка и
содержит:
 сведения об операторе;
 имя процедуры/команды;
 признаки режима выполнения процедуры/команды;
 необходимые исходные данные/параметры.
149
Особенностью программного анализа директив является обеспечение защиты
программного обеспечения оборудования станции от непродуманных вмешательств обслуживающего персонала.
Во всех случаях, когда вводимая оператором операция не соответствует размещенным, оператору выводится сообщение об ошибке, либо о невозможности выполнения директивы.
На рис. 7.5 представлена граф-схема алгоритма реализации эксплуатационной процедуры. Большая работа по стандартизации языков MML, используемая для современных цифровых систем коммутации проведена МСЭ–
Т.
Впервые проблемой централизации управления сетями электросвязи
начали заниматься в 1950-х годах. Центр управления сетью контролирует состояние оборудования станций и узлов, а также каналов связи при помощи
систем и платформ управления, которые с соответствующей периодичностью
будут осуществлять мониторинг состояния сети телекоммуникаций и услуг
связи.
При появлении отдельных повреждений в оборудовании связи, центр управления сетью обеспечивает идентификацию и локализацию поврежденных
приборов и отдельных блоков, а также переключает отказавшее оборудование на резервное. Кроме того, центр управления сетью отслеживает потоки
трафика, формирует данные для учета и тарификации соединений и сеансов
связи для последующих расчетов с пользователями.
Данный метод в целом называют программно- корректируемым или
качественным, поскольку характеризует качество соединения и прохождение
информации. Внедрение этого метода связано с созданием широкого набора
программ для диагностики состояния оборудования, определения и локализации места повреждения, переключения неисправного оборудования на резервное.
Программно- корректируемый метод эксплуатации соответствует системе обслуживания коммутируемой техники с помощью управляющих
ЭВМ.
Число станций и узлов, обслуживаемых одним узлом управления сетью, зависит от времени приезда ремонтной бригады к наиболее удаленной
станции зоны обслуживания.
В итоге основными функциями центров управления сетью в части технической эксплуатации являются:
150
Начало
Запуск команды
MML на
исполнение
Вывод
сведений
ТЭ
Установка
приоритета
команды MML
Формирование
команды MML
Нет
Ввод команды
MML
Нет
Проверка
семантики и
синтаксиса MML
Нет
Команда
корректна?
Время
обработки
истекло ?
Диспетчер
программ
ОС
Обработка
команды MML
Команда
исполнена?
Да
Да
Да
Останов
Рис. 7.5 – Граф-схема алгоритма выполнения команды MML
Прием и отображение сигналов, приходящих с обслуживаемых станций, организация устранения аварии в случае аварийных ситуаций.
2. Прием, обработка и анализ информации о трафике и результатах
контроля качества обслуживания вызовов.
3. Оперативный контроль состояния и функционирования оборудования в реальном масштабе времени;
4. Прием заявок от абонентов и проверка своевременного их устранения;
5. Проведение контрольных тестов и регламентных работ по диагностированию оборудования.
При организации центров управления сетью следует обеспечить наличие:
 технических средств контроля диагностики обслуживаемого оборудования, а также возможности сбора информации о качестве его работы.
 средств обмена информацией по управлению, например, возможность подключения каналов передачи данных;
 программно-аппаратных средств накопления и обработки поступающей контрольной диагностической информации с узлов связи;
1.
151
 нахождение в штате квалифицированных бригад специалистов,
оснащенных необходимыми техническими и транспортными средствами.
В целом задачу технического обслуживания на сети связи можно разделить
на две основные части:
Эти задачи дают возможность прогнозировать ошибки и их распределение в течение определенной проверки. Наиболее приемлемым для решения
данных задач является использование распределенной модели обслуживания
с внедрением минимальных, максимальных, целевых показателей.
7.4 Контрольные вопросы к разделу 7
1. Что такое «техническая эксплуатация»?
2. Какие существуют основные методы технической эксплуатации?
3. В чем особенность профилактического метода технической эксплуатации?
4. Какие работы включают профилактические проверки средств связи?
5. Для чего на сетях связи проводятся измерения?
6. Какие уровни измерений могут проводиться в рамках телекоммуникационных систем?
7. Какие измерения проводятся для электрических кабелей связи?
8. Какие измерения проводятся с помощью переменного тока?
9. Что входит в состав статистического контрольно–корректирующего
метода?
10. Для чего применяется язык MML?
152
РАЗДЕЛ 8. ПРОТОКОЛ SNMP ДЛЯ УПРАВЛЕНИЯ СЕТЯМИ
СВЯЗИ
8.1 Общие сведения о протоколе SNMP
Протокол управления SNMP относятся к протоколам прикладного
уровня семиуровневой модели взаимодействия открытых систем. Основное
назначение данного протокола состоит в передаче управляющего воздействия от менеджера к агенту, а также передача уведомления/подтверждения о
результатах, к которым привело управляющее воздействие. Таким образом,
протокол SNMP поддерживает информационную модель TMN, но не является официально признанным в рамках стандартов МСЭ-Т по TMN.
Улучшенная версия протокола SGMP была переименована в простой
протокол управления сетью (Simple Network Management Protocol, SNMP).
Протокол SNMP получил статус временного решения. Для долгосрочного
применения планировалось проанализировать один из протоколов, базирующихся на семиуровневой модели ВОС : СМОТ или СMIP. Но в итоге протокол SNMP стал постоянным техническим решением. Начиная с 1990 г. протокол SNMP версии 1 (SNMPv1) становится базовым протоколом управления
в сети Интернет. Как альтернатива более масштабным, но зато и более дорогим решениям CMIP, протокол SNMP получил особенно широкое распространение начиная с 1993 года в качестве базового протокола управления сетями, использующими стек протоколов TCP/IP. С помощью SNMP осуществляется управление как одиночными устройствами, так и группами сетевых средств, в том числе крупными сетями связи (информационновычислительными сетями).
На протяжении 1990-х годов протокол SNMP неоднократно рассматривался и дорабатывался неправительственной международной организацией
Инженерная группа по развитию Интернета (Internet Engineering Task
Force, IETF). В настоящее время протокол SNMP применяется на сетях, использующих стек протоколов TCP/IP, и на сетях, использующих другие телекоммуникационные протоколы.
Основным нормативным документом, определяющим концепцию
управления и администрирования сетями, использующими стек протоколов
TCP/IP, является документ RFC 1157 «Simple Network Management Protocol
(SNMP)», который разработан специалистами IETF. Деятельность по стандартизации SNMP продолжается постоянно. Сеть связи в рамках протокола
SNMP представляется как совокупность сетевых управляющих станций и
элементов сети (шлюзы, маршрутизаторы, коммутаторы); на элементах сети
поддерживается программы-агенты, с помощью протокола UDP обеспечивается обмен информацией управления между сетевыми управляющими станциями и агентами.
153
В настоящее время практически применяются две версии протокола
SNMP: SNMP Version 1 (SNMPv1) и SNMP Version 2 (SNMPv2) [37, 39]. Обе
версии имеют много общего, однако SNMPv2 предоставляет некоторые преимущества, например дополнительные операционные возможности протокола, поддержку средств аутентификации. Стандартизация версии SNMPv3 завершается. В настоящей главе в качестве основной версии протокола SNMP
рассматривается версия 2. Учитывая существенный объём источников информации по протоколу SNMP и доступность данных источников, обсуждение протокола SNMP будет проведено в сжатой форме. В качестве источников информации использовались данные сети Интернет с сайтов
http://www.simpleweb.org/,
http://www.citforum.ru
и
http://www.laes.ru/list/pve/SNMP/.
Как уже говорилось, при использовании протокола SNMP программа
пользователя (менеджер сети) осуществляет виртуальные соединения с
SNMP-агентом. Программа SNMP-агента установлена на элементе сети, и
предоставляет менеджеру сети информацию о состоянии данного элемента.
Этот процесс осуществляется в рамках системы управления сетью (network
management systems, NMS) согласно модели, представленной на рис. 8.1. Существуют некоторые отличия понятия «управляемый объект» в протоколах
CMIP и SNMP. Управляемый объект в протоколе CMIP  это законченное и
подробное описание управляемого ресурса; управляемым объектом в протоколе SNMP является чаще всего некоторый атрибут объекта, например число
отказов или сбоев.
Система управления сетью NMS
Условные
обозначения:
Сообщения и
команды
протокола SNMP
Менеджер
элементов сети
Приложение
управления
SNMPv2
менеджер MIB
Интерфейс
пользователя
Сеть связи с
использованием стека
протоколов UDP/IP
Менеджер
элементов сети
SNMPv2
менеджер MIB
или агент
SNMPv2
менеджер MIB
или агент
ЛВС
SNMPv2
агент
MIB
Элемент сети
SNMPv2
агент
MIB
SNMPv2
агент
MIB
Элемент сети
Элемент сети
154
Рис. 8.1 – Использование протокола SNMP версии 2
Как уже отмечалось, управляемое устройство, на котором функционирует программа-агент, может быть любым – сервер доступа в Интернет,
УПАТС, принтер, маршрутизатор, концентратор ЛВС и т.п. В данной ситуации программы управления должны быть построены таким образом, чтобы
минимизировать воздействие программы-агента на управляемое устройство;
другими словами, функционирование агента не должно влиять на выполнение основных функций средств связи.
Агенты по заданию менеджера или автоматически (по расписанию) могут отслеживать следующие показатели работы оборудования:
 Число и состояние виртуальных каналов.
 Число определенных видов сообщений о неисправности.
 Число входящих и исходящих байтов (пакетов) для данного устройства.
 Максимальная длина очереди на входе/выходе (для маршрутизаторов и
других устройств).
 Отправленные и принятые широковещательные сообщения.
 Отказавшие и вновь запущенные в эксплуатацию сетевые и абонентские интерфейсы.
База данных с информацией о состоянии элементов сети Интернет
установлена ISO и называется Интернет-информационной базой управления
(Internet management information base, IMIB) [38,42]. База IMIB является виртуальным информационным массивом, который подобно базе данных MIB
содержит в формализованном и упорядоченном виде информацию, связанную с сетью связи и с сетевым оборудованием. В протоколе SNMP база IMIB
также является информационной моделью управляемого объекта, однако
уровень её подробности ниже, чем в протоколе CMIP. Стандартная IMIB
протокола SNMP включает различные объекты/элементы, создаваемые с целью измерения, мониторинга и контроля функционирования протоколов
IP,TCP,UDP, контроля IP-маршрутов, TCP-соединений, состояния сетевых
интерфейсов элементов сети в целом. При управлении протокол SNMP обращается за информацией именно к MIB.
Существует два стандарта IMIB, применяемых в протоколе SNMP, а
именно стандарт MIB I и стандарт MIB II. Кроме того, существует версия
MIB для удалённого управления с помощью агентов протокола удалённого
мониторинга сетей (Remote Monitoring, RMON). Протокол RMON в данном
пособии детально не рассматривается.
В стандарте MIB I (см. нормативный документ RFC 1156) определены
только операции чтения из базы. В этой версии существует 8 групп управляемых объектов, всего 114 объектов. Например, группа System содержит объекты, которые позволяют описать общие данные об устройстве – обозначение поставщика, время последнего включения/активизации устройства;
155
группа IP включала данные протокола IP (адрес IP-шлюза, статистика IPпакетов).
Каждый из управляемых объектов связан (ассоциирован) с именем и
со специальным объектным идентификатором. Объектный идентификатор
представляет собой формальный регистрационный признак (номер) объекта
управления, под которым управляемый объект занесён в IMIB.
Совокупность объектных идентификаторов образуют т.н. «дерево регистрации» управляемых объектов, основные «ветви» которого контролируются и поддерживаются Международной организацией по стандартизации
(идентификатор iso), МСЭ (ccitt или itu), организациями, сотрудничающими
с МСЭ (идентификатор jointtoccitt).
Пример рассматриваемого дерева регистрации управляемых объектов
приведён далее на рис.8.2. Следует отметить, что на практике для записи
данных об управляемых объектах используется специальный язык абстрактной записи синтаксиса №1 (Abstract Syntax Notation No1). Язык
ASN.1 является универсальным способом записи данных об управляемом
объекте т.к. не зависит от языка программирования, который применяется
для разработки программных приложений управления.
root
ccitt(0)
iso(1)
joint-iso-ccitt(2)
org(3)
internet(1)
dod(6)
mgmt(2)
privat(4) snmpv2(6)
mib(1)
system(1)
sysObjectID(2)
snmp(11)
sysUpTime(3)
Рис. 8.2 – Схема «дерева» регистрации объектных идентификаторов
управляемых объектов в сети Интернет
Например, объект с именем «sysUpTime», значение которое указывает
время в сотнях секунд, истекшее с момента перезагрузки/ управляемого
156
устройства, связан с объектным идентификатором OID system 1.3, с регистрационным номером 1.3.6.1.2.1.1.3.0, который соответствует ветви дерева
идентификаторов (сверху вниз): iso(1)  org(3)  dod(6) internet(1) 
mgmt(2) mib-2(1)  system(1)  sysUpTime(3)  0. Эту запись следует
понимать так : объект зарегистрирован в «ветви» дерева идентификаторов,
которое поддерживается ISO, находится в домене, относящимся к организациям (org) поддерживается Министерством обороны США (department of defense, dod), относится к сети Интернет (internet), применяется для решения
задач управления (mgmt), зарегистрирован в базе данных MIB (mib-2), относится к группе системы (system), обозначается sysUpTyme (3) и является дискретным (0) Вершина root является глобальной ссылкой (точкой отсчёта) и
содержательного смысла не имеет.
8.2 Информационная модель управления MIB SNMP
Структура и описание базы данных с информацией о состоянии элементов сети на основе протокола IP установлена ISO и называется информационной базой управления сети интернет (Internet management information
base, IMIB). База IMIB является виртуальным информационным массивом,
который содержит в формализованном и упорядоченном виде информацию,
связанную с сетью связи и с сетевым оборудованием. В протоколе SNMP база IMIB также является информационной моделью управляемого объекта,
однако уровень её подробности ниже, чем в протоколе CMIP. Стандартная
IMIB протокола SNMP включает различные объекты/элементы, создаваемые
с целью измерения, мониторинга и контроля функционирования протоколов
IP,TCP,UDP, контроля IP-маршрутов, TCP-соединений, состояния сетевых
интерфейсов элементов сети в целом. При управлении протокол SNMP обращается за информацией именно к IMIB.
Существует два стандарта IMIB, применяемых в протоколе SNMP, а
именно стандарт MIB I и стандарт MIB II. Кроме того, существует версия
MIB для удалённого управления с помощью агентов протокола удалённого
мониторинга сетей RMON (Remote Monitoring). Протокол RMON в данной
монографии детально не рассматривается.
В стандарте MIB I (см. нормативный документ RFC 1156) определены
только операции чтения из базы данных. В этой версии существует 8 групп
управляемых объектов, всего 114 объектов. Например, группа System содержит объекты, которые позволяют описать общие данные об устройстве –
обозначение поставщика, время последнего включения/активизации устройства; группа IP включала данные протокола IP (адрес IP-шлюза, статистика
IP-пакетов).
Каждый из управляемых объектов связан (ассоциирован) с именем и
со специальным объектным идентификатором. Объектный идентификатор
157
представляет собой формальный регистрационный признак (регистрационный номер) объекта управления, под которым управляемый объект занесён в
IMIB. Совокупность объектных идентификаторов образуют т.н. «дерево регистрации» управляемых объектов, основные «ветви» которого контролируются и поддерживаются Международной организацией по стандартизации
(идентификатор iso), МСЭ (ccitt или itu), организациями, сотрудничающими
с МСЭ (идентификатор jointtoccitt).
Основные группы объектов IMIB, по аналогии с приведённым примером, можно изобразить в виде абстрактного дерева, «ветвями» которого являются отдельные группы управляемых объектов (см. рис. 8.3.).
MIB-II
System (mib-2 1)
SNMP (mib-2 11)
Interfaces (mib-2 2)
Transmission (mib-2 10)
Address translation
(mib-2 3)
Exterior Gateway
Protocol (mib-2 8)
IP (mib-2 4)
User Data Protocol
(mib-2 7)
ICMP (mib-2 5)
TCP (mib-2 6)
Условные обозначения :
mib-2 x – объектный идентификатор
System – группа системы (содержит имя домена, физическое расположение
узла, описание сервисов узла)
Interfaces – группа сетевых интерфейсов (содержит описание вида интерфейса, данные о скорости передачи, сведения о рабочем состоянии)
Address translations – отображение IP-адресов в физические адреса
IP (Internet Protocol) – группа протокола межсетевого взаимодействия
ICMP (Internet Control Message Protocol) – группа сообщений межсетевого
протокола управляющих сообщения
TCP (Transaction Control Protocol) – группа протокола управления передачей
UDP (User Data Protocol) – группа протокола дейтаграмм пользователя
Exterior Gateway Protocol – группа протоколов для взаимодействия маршрутизаторов
Transmission – данные о среде передачи информации
SNMP – данные статистической информации протокола SNMP
Рис. 8.3 – Структура MIB II
В стандарте MIB II (см. RFC 1213), который действует с 1992 г. количество управляемых объектов увеличено до 185, а количество групп – до 10.
158
Сущности, с помощью которых можно описать объекты управления и
ТЭ, обычно идентифицируются и описываются с помощью таблиц. Каждая
группа состоящая из сущностей в MIB II на практике представлена в виде
одной или нескольких таблиц. Таблица может включать скалярные величины, соответствующий конкретному значению атрибута управляемого объекта.
Например,
таблица
tcpConnTable,
регистрационный
номер
1.3.6.1.2.1.6.13.1, которая содержит данные о TCPсоединениях элемента сети (группа TCP mib2-6), предложенная компанией Cisco Systems, имеет вид
(см. рис. 8.3).
TcpConnState
tcpConnLocalAd-
TcpConnLocalPort
…
dress
(значение 1)
(значение 3)
(значение 5)
…
(значение 2)
(значение 4)
(значение 6)
…
…
…
…
…
(значение I)
(значение J)
(значение K)
…
Условные обозначения :
TcpConnState  обозначает состояние TCPсоединения, значение – целое
число, INTEGER.
TcpConnLocalAddress  обозначает IPадрес инициатора соединения, его
значение соответствует IPадресу (IpAddress).
TcpConnLocalPort  обозначает номер порта, через который осуществляется
соединения, целое число (INTEGER).
Рис. 8.3 – Пример таблицы SNMP, отображающей состояние
TCPсоединения
Сущности MIB объединены в 5 групп объектов MIB, среди которых
есть три группы, имеющих непосредственное отношение к задаче технического учёта объектов управления. Это группы :
entityPhysical group – описывает физические сущности, управляемые
одиночным агентом. Данные содержатся в таблице entPhysicalTable.
entityLogical group – описывает логические сущности, управляемые
одиночным агентом. Данные содержатся в таблице entLogicalTable.
entityMapping group – описывает взаимосвязи (ассоциации) между физическими сущностями, логическими сущностями, интерфейсами, неинтерфейсными портами, которые в совокупности управляются одиночным агентом. Данные содержатся в трёх различных таблицах.
159
Физическая сущность или физический компонент представляют собой
идентифицируемые физические ресурсы внутри управляемой системы. Физические сущности описываются в IMIB c помощью логических сущностей,
которые по сути являются абстрактно-логической реализацией множества
объектов IMIB. Каждый физический компонент устройства связи представлен в виде логического описания в таблице entPhysicalTable; эта таблица
поддерживается агентом на данном устройстве/средстве связи. При этом физические ресурсы (телекоммуникационные порты, монтажные платы, монтируемые модули, источники электропитания), которые могут управляться и
контролироваться с помощью функций управления, ассоциированы (логически связаны) с одной или несколькими логическими сущностями, включенными в IMIB. Итак, по сути, при передаче команды управления имеет место
взаимодействие с программной средой. Далее с помощью внутрисистемного
функционального интерфейса команда транслируется на реальный физический объект. По результатам этой трансляции содержание таблицы IMIB может обновляться.
С помощью табличных объектов (таблиц) IMIB должен идентифицироваться и описываться каждый физический объект или монтируемое устройство. При это структура IMIB для различных сетевых элементов, в том числе
от различных производителей, может отличаться.
Таблица entPhysicalTable содержит одну строку (row) для описания
каждой физической сущности и по крайней мере, одну «глобальную» строку
для физических сущностей, соответствующих значению класса объектов
entPhysicalClass :
Сhassis – монтажное устройство (группа позиций) для группы телекоммуникационных устройств; Сhassis может содержать Container; в свою
очередь Chassis может находиться только в составе Stack.
Вackplane – задняя (монтажная) панель или кабельная укладка.
Container – соответствующая физическая сущности, описывающая
устройство, способное конструктивно объединять несколько разнотипных,
оперативно заменяемых устройств (ТЭЗ, FPU)
powerSupply – устройство электропитания.
fan – вентилятор или другое устройство для снижения температуры.
Module – автономное, независимая подсистема; в случае возможности
оперативной замены данное устройство рассматривается как отдельная сущность.
Port – описание физической сущности, функционально способной принимать/передавать сетевой трафик.
Stack – описание физической сущности, которая представляет собой
объединение, иногда виртуальное, несколько объектов Container, для соединения между собой нескольких шасси (Chassis).
Other – не совпадает ни с одним из перечисленных классов физических
сущностей.
160
Unknown – данный класс физических сущностей существует, но неизвестен агенту.
Каждая строка индексируется целым произвольным числом и содержит
описание и тип физической сущности. Также данная строка может содержать индексный номер другой entPhysicalEntry для указания на отношения
включения между этим двумя сущностями. Для MIB, описывающей физические сущности, может быть назначено несколько объектов только с возможностью чтения (read-only). Пример см. в таблице 2.8:
Базы IMIB могут описывать сетевой элемент с помощью следующих
объектов :
Одна общая (порождающая) таблица.
Общая таблица с дополнительной информацией (с расширением).
Множество различных (в том числе разнесённых по различным
устройствам) таблиц.
Таблица 8.1 – Описание объектов учёта для транспортных сетей и сетей доступа согласно структуре MIB-II протокола SNMPv2
Наименование
объекта
1
entPhysicalName
Описание объекта
2
Это текстовое наименование физической сущности,
которая соответствует определённому компоненту в
составе устройства и применяется в командах NMS.
entPhysicalHardwareRev Строковая переменная, формируемая производителем
компонента, которая указывает на идентификатор номера редакции (версии) физического компонента. Эта
версия, как правило, может быть указана на самом
компоненте.
entPhysicalFirmwareRev Строковая переменная, зависящая от производителя
компонента, которая указывает на номер редакции
(версии) замонтированного программного обеспечения
(firmeware) для данной физической сущности. Допускается нулевое значение.
entPhysicalSoftwareRev Строковая переменная, зависящая от производителя
компонента, которая указывает на номер редакции
(версии) загружаемого программного обеспечения для
управления данной физической сущностью. Допускается нулевое значение.
entPhysicalSerialNum
Зависящая от производителя строка, которая содержит
серийный номер физической сущности. Этот серийный
номер, как правило, может быть указан на физическом
компоненте. Если серийный номер неизвестен, то он
может устанавливаться в нулевое значение. Не всякий
161
Наименование
объекта
1
entPhysicalMfgName
entPhysicalModelName
entPhysicalIsFRU
entPhysicalAlias
entPhysicalAssetID
entLogicalIndex
Описание объекта
2
физический компонент может иметь серийный номер
или не каждому физическому компоненту такой номер
требуется. В частности, физические сущности для которых значение объекта entPhysicalIsFRU = false(2)
(например, отдельный порт в модуле из 8 портов), не
нуждаются в собственном серийном номере. Этот номер присваивается модулю в целом.
Наименование производителя физического компонента.
Зависящая от производителя обозначение, соответствующее наименованию модели физического компонента в виде строки-идентификатора. Это значение
устанавливается согласно номера (части номера), задаваемого производителем оборудования.
Этот объект указывает на то, является или нет данная
физическая сущность заменяемым элементом FPU
(ТЭЗом) c точки зрения производителя. Если значение
данного объекта равно true(1), то физическая сущность
является ТЭЗ. Для физических сущностей, которые
описывают компоненты, находящиеся в составе ТЭЗ,
соответствующее значение равно false(2).
Строковая переменная, которая используется системой
сетевого управления как долговременный (стабильный
во времени) идентификатор физических компонент.
При этом генерацию данного идентификатора может
осуществить агент управления по определённому алгоритму на основе значения entPhysicalClass. Документ
RFC 2737 признаёт неэффективным поддерживание
иными средствами данного идентификатора для каждой физической сущности.
Cтроковая переменная предназначена для хранения
специфичных для пользователя идентификаторов объектов для заменяемых физических компонент. Для того, чтобы снизить размеры памяти, необходимые для
данного агента, администратор сети должен только
установить идентификаторы для физических сущностей, которые являются заменяемыми (перемонтируемыми) т.е. не находящимися постоянно внутри какой
то физической сущности.
Значение данного объекта является уникальным обо162
Наименование
объекта
1
entLogicalDescr
entLogicalType
entLogicalTAddress
entAliasMappingTable
Описание объекта
2
значением логической сущности.
Тестовое описание логической сущности. В составе
описания должна бать информация об имени производителя и обозначение версии логической сущности.
Обозначает тип логической сущности, соответствующий как правило имени OBJECT IDENTIFIER для
данного узла связи. При этом данная логическая сущность рассматривается как способ описания модулей
MIB, которые относятся (приписаны) к данной сущности. Например, маршрутизатор как логическая сущность относится к ветви mib-2, логическая сущность
повторителя 802.3 «802.3 repeater» обозначается как
snmpDot3RptrMgmt.
Услуги транспортного уровня ВОС, относящиеся к
данной сущности в части, связанной с получением
трафика сетевого управления согласно домена, указанного с помощью значения объекта entLogicalTDomain.
Таблица содержит нулевое или ненулевое количество
строк, которые указывают на отображение логических
сущностей и физических компонент на внешние идентификаторы MIB. Каждый физический порт средства
связи может быть отображён на внешний идентификатор, который в свою очередь связан с соответствующим множеством имён логических сущностей.
Когда физические сущности описываются в одной общей таблице, то
все сущности присутствуют в единой таблице и каждая сущность описывается с помощью собственной строки в этой общей таблице. В большинстве
случаев, эта общая таблица прямо или косвенно основана на сущности MIB
под названием ENTITY-MIB entPhysicalTable в документе RFC 2737 c учётом
положений ранее действовавшего, но вышедшего из употребления документа
RFC 2037.
Отметим, в частности, что для оборудования Cisco 7600 описание объектов
MIB
SNMP
доступно
по
ссылке
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en/
Согласно материалам компании Cisco Systems, при формировании MIB
таблица entPhysicalTable содержит два управляемых объекта, которые описывают взаимосвязи с «родительскими» объектами :
163
Таблица 8.2 – Пример описания коммутатора Nortel Business Policy Switch 2000 в базе
данных MIB-II
entPhysi entPhysical
ca lDescr VendorType
1
2
3
…
10
….
33
34
….
85
Business
Policy
Switch
2000
Stack
Business
Policy
Switch
2000
10-Base
10/100
Ethernet
Port
….
10-Base
10/100
Ethernet
Port
….
CASCA
DE Slot
8
port
CASCA
DE
Module
….
s5ChasTypeBP
S2000
10-Base
10/100
Ethernet
Port
entPhysica entPhysical entPhysical
l
Class
Name
Contained
In
0
stack(11)
stack
s5ChasComBrd
BPS2000_24T
1
chassis(3)
switch-1
0.0
2
port(10)
port-1
….
0.0
….
2
….
port(10)
….
port-8
….
0.0
….
2
….
….
container(5) cascade-slot
33
module(9)
cascade
….
….
….
….
0.0
84
port(10)
port-1
164
Таблица 8.3 – Пример описания коммутатора CISCO 7600 MIB
entPhysical
Descr
1
2
3
5
1000
2000
2001
2053
entPhysicalVendo entPhysi entPhysical
r Type
cal
Class
Contain
edIn
Cisco Sys- OID: enterprises.
0
chassis(3)
tems Cisco 9.12.3.1.3.267
7600 3-slot
Chassis System
Cisco Sys- OID:
1
container(5)
tems Cisco .ccitt.zeroDotZero
7600 3-slot
Physical
Slot
Cisco Sys- OID:
1
container(5)
tems Cisco .ccitt.zeroDotZero
7600 3-slot
Physical
Slot
1
backplane(4)
Cisco Sys- OID:
tems Cisco .ccitt.zeroDotZero
7600 3-slot
backplane
2
module(9)
OID:
WS-X6KSUP2-2GE enterprises.9.12.3.1
2 ports Cata- .9.29.20
lyst
6000
supervisor 2
Rev. 3.10
WS-X6148- OID:
3
module(9)
RJ45V 48- .ccitt.zeroDotZero
port 10/100
mb
RJ45
Rev. 1.0
module
2 OID:
2000
sensor(8)
power.ccitt.zeroDotZero
output-fail
Sensor
10/100Base OID:
2000
port(10)
TX
.ccitt.zeroDotZero
165
entPhysical
Name
CISCO7603
Backplane
1
2
module 2 power-output-fail
Sensor
Fa2/48
 entPhysicalContainedIn – этот объект описывает таблицу индексов
entPhysicalIndex физических сущностей, представляя собой «родительский» объект для этих сущностей. К примеру, физическая сущность описывает монтажную позицию или посадочное место/гнездо
(slot) в шасси (стойке), обычно содержащую физическую сущность,
описывающую линейный модуль (line card). Монтажное место является родительским объектом по отношению к линейному модулю.
 entPhysicalParentRelPos – этот объект содержит целочисленные значения, которые описывают связи данной физической сущности с
«родительским объектами». К примеру
физической сущности,
описывающей монтажную позицию будет присвоено значение
entPhysicalParentRelPos, равное номеру позиции физической позиции в шасси, которую сущность описывает.
Таблица entPhysicalContainsTable представляет собой перечисление/список всех «дочерних» объектов для каждой физической сущности в
рамках рассматриваемой системы. Эта таблица представляет отношения
между родительскими и дочерними объектами. Кроме уже перечисленных
объектов, в таблице сущностей entPhysicalTable по версии Cisco Systems могут включаться следующие сущности :
entPhysicalIndex—индекс для уникальной идентификации каждой
сущности в шасси/стойке/стативе. Это индекс также используется для доступа к информации данной таблицы в том числе параметров объекта со стороны сущностей в других MIB;
entPhysicalContainedIn— обозначает entPhysicalIndex сущностей, описывающих «родительские» компоненты;
entPhysicalParentRelPos— показывает индекс позиции сущностей, описывающих
однотипные
объекты,
имеющие
схожие
значения
entPhysicalContainedIn
(к примеру, монтажные позиции шасси/стойки/статива и порты линейного модуля).
Здесь возможно использовать т.н. «контейнер» т.е. объект который
применяется, если данный класс объектов – физических сущностей – способен
содержать
одну
или
несколько
монтируемых/перемонтируемых/удаляемых физических сущностей. К примеру, каждая заполненная или пустая монтажная позиция может рассматриваться как
контейнер в отношении физических портов на линейной карте. Все монтируемые физические сущности должны моделироваться как входящие в состав
некоей сущности контейнеры, это относится в том числе к источниками
электропитания на полке статива или к вентиляторам на полке статива. Дополнительно опишем смысловое значение столбцов таблицах 8.2 и 8.3 :
entPhysicalDescr – даёт текстовое описание сущности;
entPhysicalClass – обозначает базовый тип аппаратного средства, которое описывается с помощью данной физической сущности. Агент присваивает стандартное счётное значение которое точно соответствует базовому
классу физической сущности. Если не существует приемлемо стандартного
166
идентификатора для регистрации данной сущности то используется значение «other(1)». Если значение объекта неизвестно агенту, то в ответ на запрос
возвращается значение «unknown(2)».
Для использования протокола SNMP в целях организации технического учёта и паспортизации необходимо установить соответствие между табличными объектами и сущностями, атрибутами классов объектов учёта в базе данных NRM.
Анализ примеров таблиц 8.2 и 8.3 показывает, что MIB-II можно использовать в качестве источника информации о конфигурации функциональных элементов сети, в том числе узлов доступа, о конфигурации сетевых узлов на первичных сетях, о конфигурации узлов передачи данных на сетях переноса. Такая информация может быть предоставлена в случае, если оборудование связи поддерживает агента SNMPv2. В результате можно получить
оперативную информацию о составе объекта управления и учёта в текстовом
виде. Это касается только тех объектов, которые стандартным образом зарегистрированы с помощью программы-агента.
Информация, получаемая с помощью протокола SNMP в рамках данной информационной модели управления, требует дополнительной интерпретации. В частности, если на основе информации SNMP строить двумерную модель объекта в виде чертежа с нанесенными стойками, монтажными
позициями, платами, то необходимо будет дополнительно анализировать информацию SNMP с учётом «родительских отношений» между объектами,
чтобы отразить размещения объектов по степени «вложения» на двумерной
графическую схему объекта. Информации о пассивных компонентах – кабелях связи, кроссах, муфтах, особенностях их соединения и монтажа протокол
SNMP не предоставляет.
Директивы или управляющие команды, выданные сетевым менеджером агенту, наряду с собственно командами состоят из идентификаторов
объектов MIB, значение которых следует получить. Поэтому команды управления в SNMP используются в первую очередь для получения текущего значения или установки нового значения атрибута объекта управления с соответствующим идентификатором. В тоже время существует возможность с
помощью элементов MIB создавать описания в IMIB новых объектов.
8.3 Элементы протокола SNMP
В протоколе SNMP можно выделить следующие основные стандартизованные элементы.
1. Стандартный формат сообщения (standard message format), который определяется форматом сообщения UDP.
2. Стандартный набор управляемых объектов (standard set of managed
objects) представляет собой набор стандартных значений объектов и
их значений (values) атрибутов в IMIB, которые можно получить в
ответ на запросы сетевой станции управления. Значение, получае167
мое в ответ на запрос (т.н. возвращаемое значение) позволяет сделать вывод о состоянии управляемого объекта. Стандартный набор
включает величины для текущего контроля протоколов TCP, IP,
UDP и сетевых интерфейсов устройств. Каждая величина ассоциирована с к объекту с объектным идентификатором, выраженным в
записи через точку (dot-notation), как это показано в разделе 8.2.
3. Стандартный способ добавления объектов (standard way of adding
objects). Наличие этого элемента  одна из причин того, почему
протокол SNMP стал широко известным и приобрел статус defacto
промышленного стандарта управления. Наличие такого метода позволяет фирмам-производителям расширять стандартный набор
управляемых объектов посредством спецификации новых объектов
и добавления их в IMIB.
Начиная с протокола SNMP версии 1 были определены четыре типа
стандартных SNMP-операций для управления объектами :
 операция Get [получить]  применяется чтобы возвратить (получить) значение атрибутов управляемого объекта из группы IMIB;
 операция GetNext [получить следующий] существует, чтобы возвратить имя (и значение атрибутов) следующего по порядку управляемого объекта, который соответствует определённому сетевому
устройству. Объект имеет корректно присвоенное имя в IMIB;
 операция Set [установить]  применяется, чтобы установить на
управляемых объектах значения атрибутов;
 операция Trap [прерывание]  используется сетевыми устройствами
асинхронно; с помощью прерывания, остановив выполнение других
программ управления, элементы сети могут самостоятельно, без
специального запроса, сообщить менеджеру сети о возникших отказах, перегрузках и т.п.
Помимо перечисленных, в протоколе SNMP версии 2 были добавлены
новые операции, а именно :
 операция GetBulk  используется для извлечения большого числа
значений из таблиц, а не единичных значений атрибутов;
 операция Inform  позволяет одной NMS выполнять операцию Trap
на другой NMS и, соответственно, получать ответ на асинхронный
запрос;
 операция Report – позволяет агенту сообщить о состоянии управляемого ресурса; сообщение выдаётся без запроса.
Каждой перечисленной операции соответствует PDU определённого
формата. Используя перечисленные операции (команды) можно сформировать соответствующие примитивы запросов (request) т.е. сообщения для обмена между менеджером и агентом.
В результате выполнения операции менеджером или агентом будет
сгенерирован один из следующих запросов :
168
 «Получить запрос» (GetRequest). Используется чтобы определить
технические характеристики и состояние устройства с помощью
операции Get. В результате из базы данных IMIB могут быть получены требуемые значения атрибутов управляемых объектов.
 «Получить следующий запрос» (GetNextRequest). Используется в
стандарте SNMP сетевыми менеджерами для «просмотра» всех
имен управляемых объектов и их атрибутов, которые поддерживаются агентом на данном сетевом устройстве. Эта процедура выполняется начиная с первого объекта SNMP так, чтобы после выборки информации о первом объекте перейти к выборке данных по
следующему объекту в IMIB (c использованием GetNext). Данная
процедура может повторяться до тех пор, не будет обнаружена
ошибка сетевого устройства или до конца перечня объектов IMIB.
 «Установить запрос» (SetRequest). Протокол SNMP позволяет осуществлять действия, связанные с функциональностью средства связи (через операцию «Set»), например, отключение интерфейса,
разъединение пользователей, сброс в 0 содержимого буфера вводавывода и т.д. Этот запрос обеспечивает возможность конфигурирования и управления устройствами сети с помощью протокола
SNMP.
 «Сообщение прерывания» (Trap). Протокол SNMP предоставляет
механизм, посредством которого сетевые устройства могут «выдавать наружу» (reach out) менеджеру или самим себе (через сообщение Trap) прерывание, фиксирующее наличие проблемы. Каждое
сетевое устройство было сконфигурировано так, чтобы выдать
SNMP-прерывание для одного или нескольких сетевых устройств
или менеджеров.
Соответственно, имеются и запросы InformRequest и GetBulkRequest.
Последовательность обмена перечисленными запросами (сообщениями) представлена на рис. 8.3.
169
GetRequest
Responce
InformRequest
Responce
GetNextRequest
Responce
М
е
н
е
д
ж
е
р
М
е
н
е
д
ж
е
р
GetBulkRequest
Responce
SetRequest
Responce
А
г
е
н
т
Inform
Responce
Trap
Рис. 8.3 – Обмен запросами и ответами (response) в SNMP
Все вышеупомянутые типы операций и запросов закодированы в виде
PDU, которыми обмениваются устройства, поддерживающие протокол
SNMP (см. рис.8.4 и таблицу 8.4 с описанием полей PDU) :
Get, Get-next, Set, Responce PDU
Общий заголовок SNMP
Версия СообТип Идентификатор
запроса
SNMP щество PDU
Статус
ошибки
Общий заголовок SNMP
ОбВерсия СообТип
SNMP щество PDU ласть
Тип
прерывания
Адрес
агента
Индекс
ошибки
Имя, значение
переменных
Спецкод Временпрерынaя
вания отметка
Имя, значение
переменных
Trap PDU
PDU протокола SNMP
Рис. 8.4 – Форматы PDU в SNMP (v. 1 и v.2 )
170
Таблица 8.4 – Назначение полей PDU протокола SNMP
Наименование поля
Версия SNMP
Сообщество
Назначение
Номер версии протокола SNMP
Строка символов для обмена между агентом и менеджером
Название и тип PDU Get (тип 0), Set (тип 2), GetNext (тип 1),
Responce (тип 3)
Идентификатор запро- Устанавливает связь между командами и ответами
са (Request-ID).
на команды.
Статус ошибки
Указывает ошибку и ее тип.
(Error-status).
Индекс ошибки
Устанавливает связь между ошибкой и конкретной
(Error-index)
реализацией управляемого объекта.
Имя, значение пере- Данные SNMP PDU, которые указывают на переменных
(Variable менные (атрибуты) управляемых объектов и их
bindings).
текущие значения.
Название и тип PDU Trap (тип 4)
Сообщество, область Идентифицирует тип объекта, генерирующего
(Enterprise)
данное прерывание.
Адрес агента
Содержит сетевой адрес объекта, генерирующего
(Agent address)
данное прерывание
Общий тип прерыва- Содержит общие данные об типе прерывания.
ния
(Generic trap type)
Спецкод прерывания
Содержит специфический код прерывания.
(Specific trap code)
Временнáя отметка
Содержит величину времени, прошедшего между
(Time stamp)
последней повторной инициализацией сети и генерацией данного прерывания.
Имя, значение пере- Содержит перечень переменных c информацией о
менных
(Variable прерываниях.
bindings)
Форматы PDU, которые соответствуют GetBulkRequest и Inform отличаются от вышеперечисленных. На практике форматы сообщений протокола
SNMP неудобны. Протокол SNMP не поддерживает некоторые отношения
наследования в рамках объектно-ориентированного подхода, поэтому, чтобы
получить данные о нескольких взаимосвязанных управляемых объектах,
необходимо использовать механизм многократных запросов. Следует отметить что запрос в протоколе SNMP либо выполняется полностью, либо совсем не выполняется. В целом относительная сложность протокола SNMP
171
удачно скрыта от пользователей усилиями разработчиков прикладных программных средств для сетевого управления.
Самый убедительный довод в пользу применения протокола SNMP заключается в том, что SNMP разрабатывался как протокол, поддерживающий
единый способ доступа к сетевому устройству на основе стека протоколов
TCP/IP. Коль скоро стек протоколов TCP/IP достаточно универсален, следовательно универсален и протокол SNMP. SNMP является своего рода прикладным программным интерфейсом API к сети управления. При этом сохраняется универсальность интерфейса в части доcтупа к сетевым устройствам различных видов. При отсутствии SNMP, безусловно было бы создано
большое число специальных, написанных «под заказ» протоколов, действующих только с оборудованием определенного поставщика.
Дополнительный аргумент в пользу SNMP состоит в том, что данный
протокол определяет состояние устройства без организации сложного удаленного доступа или без потребности в сложных процедурах аутентификации. В результате появляется возможность получения большого числа данных о состоянии элементов крупномасштабной сети. Однако отсутствие
надёжных средств обеспечения информационной безопасности нецелесообразно с точки зрения живучести и надёжности системы управления. Поэтому
в версии 3 протокола SNMP аутентификации и криптозащите уделено особое
внимание.
Большинство программ-менеджеров в SNMP обеспечивают следующие
функции управления :
Функции сбора информации о неисправностях (Alarm Polling
Functions). SNMP-менеджеры обеспечивают возможность установить пороги
чувствительности (thresholds) на управляемых объектах (например, максимально допустимое число ошибок), и своевременно выдавать аварийное сообщение, когда эти пороги превышены. Реализация данной функции позволяет постоянно контролировать техническую исправность сети и её отдельных элементов. Функция сбора информации о неисправностях определяет,
какие устройства отвечают на управляющее воздействие, а какие устройства
не отвечают на запросы (то есть, какие устройства условно можно считать
поврежденными).
Функция контроля тренда (Trend Monitoring Functions). На протяжении определенного времени SNMP-менеджеры обеспечивают возможность
непрерывного наблюдения за некоторыми значениями атрибутов управляемых объектов; эти объекты и значения атрибутов зафиксированы в MIB. Периодически производится считывание значений атрибутов, что позволяет
оценить рабочие характеристики сети в динамике т.е. построить тренд сети
по тому или иному признаку. В частности, описанная функция может использоваться для определения графика (профиля) нагрузки сети на заданном
интервале времени.
Функция прерывания при приеме (Trap Reception Functions). SNMPменеджеры обеспечивают возможность приёма и фильтрации SNMPпрерываний, которые выдаются сетевыми устройствами. SNMP-прерывания
172
являются важной частью протокола SNMP; прерывания позволяют сетевым
устройствам самостоятельно, не дожидаясь запроса, сообщать о проблемах,
отказах и т.п. Допустимые типы прерываний обычно регистрируются сетевым менеджером. Прерывания управляют уведомлениями о происшествиях/сетевых событиях. Поскольку прерывания выдаются в асинхронном режиме, SNMP-менеджеры поддерживают фильтрацию прерываний, чтобы
устранить сообщения о прерывании, которые являются несущественными
или вторичными (повторными).
Для реализации описанных выше функций управления используются
следующие средства, применяемые совместно с аппаратно-программной реализацией протокола SNMP :
Набор инструментов/средств управления (Management Tool Set). Все
SNMP менеджеры обеспечивают набор инструментальных программных
средств для решения задачи управления. Наиболее традиционный тип инструмента управления - программа просмотра IMIB, которая позволяет пользователю ознакомится с объектами IMIB для определенного устройства.
Набор инструментов позволяет реализовать сетевой интерфейс администратора для установки значений SNMP-агента и, следовательно, применяется
для внесения изменений в конфигурацию сети через SNMP.
MIB Компилятор (Compiler). Это средство поддерживает функцию
добавления новых объектов в MIB, например при появлении нового сетевого
оборудования. Описание нового управляемого объекта добавляется в базу
данных IMIB, после чего с помощью компилятора осуществляется кодирование и формирование исполняемого программного кода для менеджера и
агента.
Вышеупомянутая функциональность SNMP приводит к появлению
существенной нагрузки, вызванной «мониторинговым» аспектом управления
сетью связи. В протоколе SNMP достаточно велико число управляемых объектов, которые поддерживают режим доступа «только для чтения». Тем не
менее, общепризнанным достоинством SNMP является возможность с помощью относительно простых средств получать информацию о состоянии сети
и тем самым определять «здоровье» сети. Теоретически, возможности SNMP
менее мощные по сравнению с протоколом CMIP, особенно когда возникает
необходимость в модификации данных об управляемом оборудовании. В
частности, SNMP не поддерживает динамическое создание управляемых
объектов с помощью операции Create и удаление описания объектов с помощью операции Delete. Поэтому протокол SNMP не может работать с динамическими объектами, в отличии от протокола CMIP, который динамику
поддерживает. Тем не менее, использование операции Set позволяет администратору осуществлять некоторые формы корректирующего воздействия и
модификации атрибутов.
173
8.4 Особенности протокола SNMP версии 3
Основные спецификации протокола SNMP вер. 3 содержатся в документах IETF :
RFC 2570. Introduction to SNMP v3 [Введение в SNMP версии 3],
опубликован в апреле 1999 г.;
RFC 2571. An Architecture for Describing SNMP Management
Frameworks [Архитектура для описания структуры SNMP], опубликован в
мае 1999 г.;
RFC 2572. Message processing and Dispatching [Обработка и диспетчеризация сообщений], опубликован в мае 1999 г.;
RFC 2573. SNMP Applications [Приложения SNMP], опубликован в
апреле 1999 г.;
RFC 2574. User-Based Security Model [Модель безопасности пользователя], опубликован в апреле 1999 г.
Согласно данным документам, протокол SNMP версии 3 имеет следующие особенности :
 Модульность архитектуры как программных решений, так и спецификаций SNMPv3. Модульность позволяет сочетать в рамках одной
NMS компоненты от разных поставщиков, проводить модернизацию протокола и развивать его. Это гарантирует сохранность инвестиций в систему сетевого управления и способность протокола
SNMP к развитию.
 Поддержка режима распределённой обработки данных.
 Возможность работать в режиме агента, менеджера или в совмещённом режиме.
 Масштабируемость т.е. поддержание конфигурации сети произвольного масштаба и состава.
 Механизмы обеспечения информационной безопасности для защиты управляющих сообщений и разграничения доступа к информации управления.
На следующей странице, на рис. 8.5 и 8.6 представлены основные компоненты архитектуры SNMPv3 для конфигурации агента и менеджера. Основных компонентов два:
 машина протокола SNMP (SNMP engine);
 приложения управления SNMP (SNMP application).
Машина протокола SNMP присутствует во всех управляемых и управляющих системах т.е. и в менеджерах и в агентах. Машина протокола SNMP
осуществляет функции посылки и приёма PDU, функции аутентификации с
помощью вставки специальных кодов, шифрования и дешифрования сообщений, функции контроля доступа к управляемым объектам.
174
Конфигурация менеджера SNMP
Приложения управления
Генерация команд
Передача
уведомлений
Приём уведомлений
SNMP-машина
Подсистема
обработки
сообщений
Диспетчер
Подсистема
безопасности
Транспортный уровень (IPX, UDP)
Сеть связи
Рис. 8.5 – Конфигурация менеджера в SNMP версии 3
Конфигурация агента SNMP
Приложения управления
Доверенное
перенаправление
Средства MIB
Порождение извещений
Выполнение команд
SNMP-машина
Диспетчер
Подсистема
обработки
сообщений
Подсистема
безопасности
Подсистема
разграничения
доступа
Транспортный уровень (IPX, UDP)
Сеть связи
Рис. 8.6 – Конфигурация агента в SNMP версии 3
Машина SNMP, по отношению к приложениям управления, функционирует как в режиме приёма так и в режиме передачи. Машина SNMP имеет
модульную структуру и включает четыре компонента:

диспетчер (dispatcher);

подсистема обработки сообщений (message processing system);

подсистема информационной безопасности (security subsystem);
175

подсистема разграничения доступа (access control subsystem).
Диспетчер занимается приемом и отправкой SNMP-сообщений. Подсистема обработки сообщений поддерживает несколько моделей обработки сообщений, соответствующих протоколу SNMP версии 1 и версии 2. Это ключевое свойство позволяет обеспечить преемственность между различными
версиями протокола SNMP. Диспетчер выполняет функции управления
нагрузкой. Диспетчер по номеру версии в заголовке PDU определяет, какой
тип обработки сообщений необходим для данного SNMP-сообщения.
Подсистема обработки сообщений принимает/передаёт сообщения
диспетчеру. На передаче данная подсистема добавляет необходимый заголовок для передачи через сеть передачи данных; на приёме эта подсистема извлекает SNMP PDU из пакета, полученного по сети передачи данных.
Подсистема информационной безопасности (security subsystem) протокола SNMP обеспечивает функции аутентификации и шифрования. В протоколах SNMPv1 и SNMPv2 особого внимания вопросам информационной
безопасности управления не уделялось. В противоположность прежним версиям, протокол SNMP v3 включает модель обеспечения безопасности, которая предусматривает меры защиты против следующих потенциальных угроз :
 модификация информации управления при передаче;
 подмена данных, как средство неавторизованного выполнения операций управления на объекте;
 резкое увеличение потока сообщений до уровня, превышающего
обычные отклонения, возможные при использовании транспортных
протоколов TCP/IP;
 несанкционированное ознакомление с сообщениями.
При передаче подсистема безопасности получает SNMP-сообщение от
подсистемы обработки сообщений. В зависимости от требуемой услуги
управления, подсистема безопасности может шифровать PDU и часть полей в
заголовке сообщения SNMP.
Защищённое сообщение возвращается в подсистему обработки сообщений. На приёме происходит обработка сообщения в обратном порядке
(дешифровка), однако дополнительно может выполняться проверка аутентификационного кода для определения подлинности источника сообщений.
Для контроля целостности и аутентификации источника предусматриваются хэш-функции, вычисляемые на основании алгоритма криптозащиты
цифрового сообщения MD5 (message digest, MD) или алгоритма безопасного
хэширования (secure hash algorithm, SHA). Стандартным средством шифрования в SNMPv3 является стандартный алгоритм шифрования DES (data encryption standart, DES).
Протокол SNMPv3 не предусматривает специальных средств защиты
против атак на доступность, поскольку во многих случаях атаки на доступность неотличимы от потока сообщений о массовых отказах в сети, с которыми должен работать любой протокол управления.
Модель безопасности включает подсистему разграничения доступа к
информации управления. Эта подсистема обеспечивает услуги авторизации
176
для контроля доступа к IMIB в случае чтения или установки новых значений
атрибутов управляемых объектов.
Модель доступа описана в документе RFC 2275. Согласно данной рекомендации, каждый субъект управления получает т.н. представление (view)
о данных системы, а также о подмножестве информации управления, задаваемой спецификациями MIB. Это позволяет сделать доступными только те
функции, которые включены в представление.
Для операций чтения, записи и выдачи уведомлений могут использоваться отдельные представления, что повышает надёжность механизма защиты SNMPv3.
В SNMPv3 предусмотрено пять стандартных приложений управления :
 Генерация команд (command generator applications) – осуществляет
мониторинг и манипуляции с данными управления на удалённых
агентах. Использует стандартные команды из таблицы 8.4.
 Прием уведомлений/извещений (notification receiver application) – обрабатывает входящие асинхронные сообщения типа InformRequest,
Trap, Response.
 Создание уведомлений/извещений (notification originator application)
– инициирует асинхронные сообщения. Использует запросы InformRequest.
 Доверенное перенаправление (proxy forwarded applications) – использует возможности диспетчера для перенаправления сообщений
SNMP, например, по направлению к инициатору запроса или уведомления.
С учётом вышеизложенного формат сообщения SNMP v3 изменяется
(см. рис. 8.7):
msgVersion
msgMaxSise
msgFlags
msgSecurityModel
msgSecuirityParametrs
Область
шифрования
Область аутентификации
msgID
contextEngineId
contexName
SNMP Data (PDU)
msgGlobalData=
HeaderData
определяется
SecuirityModel
msgData=
ScopedPDU
(открытый или
зашифрованый
текст)
Рис. 8.7 – Формат сообщений SNMP v3
Расшифровка полей формата приведена в таблице 8.5:
177
Таблица 8.5 – Назначение полей PDU протокола SNMP v3
Наименование
Назначение
поля
Версия SNMP, устанавливается в snmpv3 (3)
msgVersion
Header data – Данные заголовка сообщения
msgID
Уникальный идентификатор, используется для
обмена между объектами SNMP для координации
запроса и ответного сообщения а также для координации обработки сообщений различными подсистемами SNMP на данном объекте. Принимает
значение от 0 до 231-1
msgMaxSize
Содержит значение максимальной длины сообщения в байтах в диапазоне от 484 до 231-1, которое может обрабатываться отправителем (источником) сообщения.
MsgFlags
Байт данных, который поддерживает три флага,
использующих три бита. Флаги указывают на
тип сообщения (Get, Set, Inform), устанавливают
порядок обмена PDU, указывают на уровень защищённости сообщения. Флаги принимают значения 0 или 1.
MsgSecurityModel
Этот идентификатор принимает значение от 0 до
231-1 и указывает на тип модели безопасности,
которая используется источником сообщения. Зарезервированные значения : 1 – для протоколов
SNMPv1; 2 – для протокола SNMPv2; 3 – для
протокола SNMPv3,
msgSecurityParametersl Байт данных, используется для коммуникации
(информационного обмена) между машиной протокола SNMP отправителя и машиной протокола
SNMP получателя сообщений. Данные в этом поле используются только подсистемой безопасности.
ContextEngineId
На приёме обозначает, совместно с полем типа в
PDU, какому приложению управления данное сообщение должно быть направлено на обработку.
При передаче указывает на приложение, которое
сформировало запрос.
ContextName
Совместно с полем contextEngineId идентифицирует конкретное содержание, которое связно с
информацией управления в PDU
SNMP Data (PDU) – данные протокола SNMP
178
Как уже отмечалось, протокол SNMP имеет несколько преимуществ по
сравнению с протоколом CMIP. Самая большое преимущество – универсальность и простота протокола SNMP. SNMP-агенты существуют для широкого
класса устройств, начиная от коммутаторов, IP-маршрутизаторов, принтеров,
ПЭВМ, источниками электропитания и жизнеобеспечения и заканчивая
АТСЭ. В результате протокол SNMP de-facto стал основным промышленным
протоколом управления для различных средств и устройств.
Протокол SNMP является достаточно гибким и расширяемым протоколом управления. Агенты SNMP могут выполнять многочисленные задания,
специфические для различных классов устройства, обеспечивая стандартный
механизм сетевого управления и мониторинга.
К недостаткам SNMP, помимо уже перечисленных, можно отнести то,
что протокол SNMP не является особенно эффективным с точки зрения сети
передачи данных, нередко сетевой ресурс используется для передачи малосущественной для целей управления информации, например версия SNMP
(передается в каждом сообщении SNMP), описание данных различной длины, которые содержатся в каждом сообщении.
Проблемы с обеспечением информационной безопасности широко используемых в настоящее время SNMP версии 1 и версии 2, существенны. В
версии 3 протокола SNMP проблемы, имевшиеся в версиях 1 и 2 с информационной безопасностью, вероятно, решены.
8.5
Контрольные вопросы к разделу 8
1. Какие технические характеристики оборудования можно контролировать
помощью протокола SNMP?
2. Каково назначение Интернет-базы данных IMIB?
3. Приведите описание стандартных операций управления в протоколе
SNMP версии 2.
4. Можно ли реализовать агента SNMP в виде отдельной ПЭВМ со специальным программным обеспечением?
5. Для каких целей в протоколе SNMP используются прерывания?
6. Опишите основные функции и средства управления протокола SNMP.
7. В чём особенности PDU протокола SNMP версии 3?
8. Какие достоинства и недостатки имеются у протокола SNMP?
179
РАЗДЕЛ 9. УПРАВЛЕНИЕ СЕТЯМИ СВЯЗИ СЛЕДУЮЩЕГО
ПОКОЛЕНИЯ
9.1 Сети NGN и особенности управления ими
Общими характеристиками NGN, определенными ITU-T и ETSI, являются разделение функций переноса информации и функций управления переносом информации через сеть, а также отделение функций услуг и приложений от собственно связных функций. Таким образом, речь идет о распределенной архитектуре, в которой связь между компонентами осуществляется
исключительно через открытые интерфейсы.
Разработкой новой сетевой архитектуры NGN занимаются несколько
организаций (ITU-T, ETSI, International Packet Communications Consortium –
IPCC, Multiservice Switching Forum – MSF и др.). Во всех версиях эталонной
архитектуры NGN присутствует некоторый элемент управления, который
может называться гибким коммутатором (softswitch), узлом (сервером)
управления обслуживанием вызовов, телефонным сервером, Call-агентом или
контроллером медиашлюзов MGC.
Сеть NGN имеет многослойную структуру – слой опорной пакетной
сети, слой управляющих серверов, независимый слой, где размещаются
платформы разнообразных услуг, и слой абонентских устройств. Причем эти
слои связаны между собой открытыми интерфейсами.
Плоскостная архитектура – краеугольный камень в NGN, она позволит
повысить эффективность операторской деятельности и предоставить открытые интерфейсы сторонним разработчикам.
Рекомендация МСЭ-Т Y.2011 «Базовая архитектура сетей следующего
поколения NGN» включает 4 основных функциональных уровня (рис. 9.1.):
Рис. 9.1 – Базовая архитектура сетей следующего поколения NGN
(согласно Рекомендации МСЭ-Т Y.2001)
180
 уровень доступа, содержащий сеть абонентского доступа к транспортной пакетной сети;
 транспортный уровень, включающий магистральную пакетную
сеть (сеть, построенную на базе протоколов пакетной коммутации);
 уровень управления вызовами, включает совокупность функций по
управлению всеми процессами в телекоммуникационной сети;
Другие сети
Функции конечного пользователя
Функции административного управления
 уровень услуг и эксплуатационного управления, который содержит логику выполнения услуг и/или приложений и управляет этими услугами, имеет открытые интерфейсы для использования сторонними организациями (для разработки программ и новых услуг).
Наиболее оптимальным будет решение, в котором перенастройка любого из вышележащих уровней не потребует никакой адаптации нижележащих – эта особенность гарантирует гибкость и универсальность системы и
способно дать реальные конкурентные преимущества компании, владеющей
подобной инфраструктурой.
На рис. 9.2 приведена архитектура сети следующего поколения NGN
согласно ITU-T.
Рис. 9.2 – Архитектура NGN согласно ITU-T
181
Одной из главных характеристик сети NGN является разделение функциональности услуг и транспорта, что позволяет развивать сервисы управления услугами, транспортные и прикладные сервисы независимо друг от друга.
Разделение представляется в виде двух функциональных уровней.
Транспортные функции относятся к транспортному уровню, а функциональность услуг лежит соответственно на уровне услуг. Горизонтальное расслоение показано на рис. 9.3, а вертикальное – на рис. 9.4.
Рис. 9.3 – Разделение функциональности услуг и транспортной сети
Существуют транспортные функции, которые тесно соотносятся с переносом цифровых данных любого вида между двумя географически разнесенными точками. Транспортный уровень может состоять из набора различных плоскостей, относящихся к уровням 1-3 эталонной модели взаимодействия открытых систем (МВОС). Таким образом, транспортные функции
предоставляют возможность соединения двух сетей различной архитектуры.
В частности, транспортный уровень обеспечивает:
 соединение пользователей между собой;
 соединение пользователей с платформами услуг;
 соединение платформ услуг между собой.
Рис. 9.4 – Базовая эталонная модель NGN
182
На транспортном уровне могут быть реализованы любые существующие сетевые технологии, включая передачу данных с коммутацией каналов
(connection oriented circuit switched, CO-CS), передачу данных с коммутацией
пакетов (connection oriented packet switched, CO-PS) и пакетную передачу информации без установления соединения (connectionless packed-switched,
CLPS) согласно рекомендациям МСЭ-Т G.805 и G.809.
Протокол IP является базовым протоколом в NGN для предоставления
как новых, так и, по возможности, существующих услуг. Платформы услуг
позволяют предоставлять пользователям такие услуги, как телефонные, Webуслуги и др. Уровень услуг, в свою очередь, может содержать сложный набор
географически разнесенных платформ формирования услуг или же, в простейшем случае, обладать функциональностью услуг, необходимой для соединения лишь двух пользователей.
Во-вторых, существует набор функций приложений, необходимых для
предоставления услуг. К таким услугам относятся голосовые услуги (включая телефонию), услуги по передаче данных (включая Web-услуги), видео
услуги (включая просмотр фильмов и телевизионных программ), или комбинацию вышеперечисленных услуг (например, мультимедийные услуги, такие
как видео-телефония или игры). Существует также множество других критериев классификации услуг (например, отложенные услуги/услуги реального
масштаба времени).
Каждый уровень может содержать несколько слоев, каждый из которых концептуально может состоять из плоскости данных пользователя, плоскости управления и плоскости менеджмента (рис.11.4).
Каждый уровень имеет определенный набор ролей, участников и административных доменов согласно рекомендации МСЭ-Т Y.110. При этом
функциональность и роль услуг не будет зависеть от транспортной составляющей. Каждый уровень необходимо рассматривать отдельно с технической точки зрения. Это достигается путем разделения слоя данных пользователя на два уровня.
Уровень услуг NGN.
Часть NGN, которая предоставляет функции передачи сервисной информации, и функции управления и менеджмента услуг и сетевых ресурсов.
Этот уровень необходим для функционирования услуг и приложений. Пользовательские услуги могут реализовываться путем рекурсии многослойных
сетей в пределах уровня услуг. Уровень услуг NGN предполагает взаимодействие услуг и приложений между равноправными объектами сети. Например,
услуги могут относиться к речевым, видео или информационным приложениям, или их комбинации в случае предоставления мультимедийных услуг. С
точки зрения архитектуры сети, каждый слой на уровне услуг содержит свои
плоскости пользовательских данных, управления и менеджмента (рис. 9.4).
Транспортный уровень NGN.
Эта часть NGN обеспечивает передачу информации и предоставляет
функции по управлению и менеджменту транспортными ресурсами. При передаче информации для целей управления и/или менеджмента устанавлива183
ются динамические или статические соединения. Транспортный уровень реализуется путем рекурсии многослойных сетей, как это показано в рекомендациях МСЭ-Т G.805 и G.809 .
С архитектурной точки зрения, каждый слой в транспортном уровне
имеет свои плоскости пользовательских данных, управления и менеджмента,
но с некоторыми уточнениями:
1. Плоскости пользовательских данных, управления и менеджмента
логически всегда присутствуют в каждом слое.
2. На практике для некоторых слоев могут отсутствовать плоскости
управления или менеджмента.
3. Согласно рекомендации МСЭ-Т G.8080/Y.1304 функции, идентич-
ные функциям плоскости управления в многослойной архитектуре, могут
быть реализованы в одном единственном протоколе. Это касается, например,
таких технологий, как оптическая сеть с автоматической коммутацией (Automatically Switched Optical Network, ASON) и обобщенная многопротокольная коммутация по меткам (Generalized Multiprotocol Label Switching,
GMPLS).
4. Согласно рекомендации МСЭ-Т М.3010 функции, идентичные
плоскости менеджмента в многослойной архитектуре, могут быть также реализованы в одном протоколе.
Общие архитектурные принципы плоскостей пользовательских данных, управления и менеджмента могут быть логически определены так, как
показано на рис. 11.4.
Кроме того, из рис. 9.4 видно, что помимо разделения функциональности услуг и транспорта, на каждом уровне также выделяются плоскости
управления и менеджмента.
В контексте сетей следующего поколения важно рассматривать:
1. Плоскость менеджмента в NGN как совокупность плоскости менеджмента уровня услуг и плоскости менеджмента транспортного уровня;
2. Плоскость управления в NGN как совокупность плоскости управле-
ния уровня услуг и плоскости управления транспортного уровня.
Поскольку рассматриваемые плоскости могут перекрываться, появляются понятия общих функций управления и менеджмента.
Важно отметить, что концепция плоскостей NGN не предусматривает
вертикальную интеграцию плоскостей, но требует наличие точек соприкосновения между идентичными плоскостями разных уровней. Данная концепция необходима для упрощения перехода от функционального рассмотрения
построения сети NGN к её практической реализации.
При создании услуг NGN используется взаимодействие функций менеджмента и управления ресурсами, как показано на рис.9.5. Этот подход
описан среди других в рекомендации МСЭ-Т M.3010. Такое же взаимодей184
ствие при создании услуг характерно для функций управления и передачи
информации.
Инфраструктурные, программно-аппаратные,
межплатформенные и базовые услуги
Ресурсы
Функции менеджмента
услуг
Функции управления
услугами
Функции менеджмента
транспорта
Функции управления
транспортом
Ресурсы
Транспорт NGN
Услуги NGN
Услуги
Функциональная транспортная область
Рис. 9.5 – Общая функциональная модель NGN
(согласно Рекомендации МСЭ-Т Y.2011)
Для поддержки мультимедийных и других услуг при обеспечении мобильности требуются хорошо проработанные функции управления. При
этом, прежде всего, должно обеспечиваться гибкое управление ресурсами сети. При разработке архитектуры NGN необходимо также детально изучить
принципы обращения пользователей к услугам (вызов услуги). В рамках разработки функциональной архитектуры NGN важно определить понятие процесса «обращения», или традиционно называемого процессом «управления».
Функции управления, вовлеченные в понятие процесса «обращения»,
можно разделить на две группы: функции, относящиеся к управлению услугами (т.е. такие функции, как идентификация пользователя, аутентификация
пользователя, управление доступом к услугам и др.), и функции, относящиеся к управлению транспортной сетью (т.е. такие функции, как управление доступом к сети, управление сетевыми ресурсами и др.).
Необходимо помнить, что другие процессы при взаимодействии пользователя с сетью так или иначе связаны с процессом «обращения». Эти процессы относятся к понятию административного управления (менеджмента)
(рекомендация МСЭ-Т М.3050.0).
Функции и процессы, относящиеся к плоскости менеджмента, описаны
в серии рекомендаций МСЭ-Т М.3050.х. Функции управления сетью (TMN)
определены в рекомендации M.3400 [350] и классифицированы согласно рекомендациям M.3010, X.700 и X.701 следующим образом:
185
управление последствиями отказов;
управление конфигурацией;
управлением учетом;
управление производительностью;
управление безопасностью.
В отличие от менеджмента и управления транспортной сетью, менеджмент услуг изучен недостаточно подробно. Однако ожидается, что менеджмент услуг будет схож с менеджментом транспортной сети (например, конфигурация ресурсов транспортной сети будет схожа с конфигурацией ресурсов услуг). Естественно, что атрибуты объектов менеджмента для транспортной сети и услуг будут при этом различаться.
Традиционная модель NGN предусматривает, что платформы для
предоставления услуг подключаются к сети связи по стандартным интерфейсам ОКС №7, SIP, Parlay, H.323. То есть с точки зрения сети связи и коммутационных элементов платформы не являются новыми элементами и могут
рассматриваться как обычные коммутационные элементы. Однако при внедрении услуг следующего поколения (Next Generation Services, NGS) разные
уровни функциональной модели начинают сливаться (рис. 9.6).





Рис. 9.6 – Функциональная модель сети NGN, адаптированная для
предоставления услуг NGS
Появляются новые виды оборудования с пограничными функциями.
Наиболее известный пример – пограничные контроллеры сессий SBC (Session Border Controller) или шлюзы уровня приложений ALG (Application Layer Gateway), сочетающие функции контроллера MGC и маршрутизатора
транспортной сети.
Уровень управления услугами должен применять одну и ту же программу логики услуги независимо от типа транспортной сети (IP, АТМ, FR и
т. п.) и способа доступа. Наличие этого уровня позволяет также вводить на
сети любые новые услуги без вмешательства в функционирование других
уровней.
Уровень управления услугами может включать множество независимых подсистем («сетей услуг»), базирующихся на различных технологиях,
имеющих своих абонентов и использующих свои внутренние системы адресации.
Уровень управления услугами выполняет элементарные функции обслуживания, которые могут использоваться провайдерами услуг для создания
более сложных или комплексных услуг. Этот уровень является также интер186
фейсом с провайдерами услуг, которые используют эти элементарные функции для доступа к основной инфраструктуре. Профиль такого доступа будет
зависеть от коммерческих соглашений между провайдерами услуг или контента и операторами сетей. Эти интерфейсы позволят разделить услуги и
технологии, используемые для их предоставления.
Общий вид всех ресурсов сети NGN представлен на рис. 9.7:
Рис. 9.7 –Взаимосвязь между аппаратными средствами и логическими
ресурсами NGN
187
9.2 Управление качеством услуг в NGN
Согласно Рекомендации МСЭ-Т G.1000 «Качество обслуживания
средств связи: структура и определения» понятие качества услуги (QoS)
формулируется как «совокупность показателей, характеризующих удовлетворенность пользователя предоставляемыми ему телекоммуникационными
услугами» [31]. При этом необходимо учитывать два понятия: провайдер
услуги и оператор сети.
Вклад провайдера услуги в формирование QoS оценивается одним эксплуатационным показателем – обеспеченность услуги поддержкой (service
support performance). Он характеризует качество работы провайдера в части
его взаимоотношений с абонентами.
Вклад оператора сети в формирование QoS оценивается тремя показателями:
 простота использования услуги (service operability performance) –
способность услуги быть просто и понятно управляемой и потребляемой пользователем;
 возможность использования услуги (serveability performance) – состоит из доступности услуги (accessibility), т. е. способности услуги
быть предоставленной пользователю по его запросу, и устойчивости услуги (retainability), т. е. способности услуги быть доступной в
течение требуемого времени;
 целостность услуги (service integrity) – способность услуги быть доступной без существенных ухудшений (показатель характеризует
способность сети передать пользователю содержание услуги без искажений).
Данные показатели качества детализируются до уровня обобщенных
сетевых показателей, которые определяются или рассчитываются на основе
частных и/или обобщенных рабочих характеристик (параметров) сети (network performance characteristics). Рабочие параметры могут быть определены,
измерены или вычислены, а также контролируемы непосредственно провайдером. Набор параметров, определяющих качество услуги, а также допустимый диапазон их значений (или пороговые значения) фиксируются в Соглашениях об уровне обслуживания (SLA).
В соответствии с рекомендацией МСЭ-T G.1000 под понятие «качество
обслуживания», помимо технических показателей предоставления услуги,
подпадает также качество взаимоотношений абонента с оператором связи.
Под этим понимается следующее:
 предварительная рекламная информация о предоставляемом спектре услуг;
 ясность и гибкость контракта;
 возможность организации линии к абоненту и подключение ее к
сети NGN;
 обеспечение безопасности обмена информацией;
188
 организация эффективных служб помощи абонентам и минимизация времени ответа справочной службы;
 точность счетов на оплату потребляемых услуг.
Анализ этого перечня позволяет сделать вывод: в сетях NGN значительное место должно отводиться нетехническим аспектам качества услуг.
В сетях NGN важным является вопрос обеспечения операторами связи
согласованного сквозного качества услуг (QoS-технологий), что приводит к
необходимости разработки соответствующих методов и принципов оценки
качества и определения соответствия последнего предъявляемым требованиям. Должна быть создана такая модель обеспечения сквозного качества, которая позволит описывать и исследовать отношения между участниками
предоставления услуги на разных стадиях их взаимодействия (рис. 9.8 ). При
этом должны быть определены требования, накладываемые каждым участником на какой-либо параметр, и устанавливаться соответствие этих требований возможностям элементов сети NGN.
Рис. 9.8 – Обобщенная модель обеспечения QoS в сети NGN
Применение данной модели даcт полную картину качества по всей сети
NGN и позволит решать вопросы сбора, учета и хранения информации о результатах контроля в едином узле с последующей обработкой, анализом и
экспертной оценкой полученной информации и вынесением решений по качеству услуги.
Как следует из этой модели основополагающим для контроля качества
услуг является установление соответствия параметров сети NGN регламентирующим значениям. Для обеспечения единства контроля необходимо провести систематизацию подлежащих контролю сетевых параметров и параметров качества предоставляемых услуг, а затем выполнить комплексирование методов их контроля (рис.9.9 ).
189
Рис. 9.9 – Преобразование контролируемых параметров NGN в сетевые показатели
На основе данной модели должен быть разработан единый подход к автоматизации процесса контроля сквозного качества услуг сети NGN, при котором учитываются характеристики линий связи, статические и динамические аспекты межузлового и сквозного качества, управления ресурсами и
адаптации приложений, а также политика управления сетью.
Дополняя отмеченные факторы учетом особенностей всей распределенной архитектуры NGN, необходимо сформировать оптимальные технические решения по измерению, анализу, тестированию и мониторингу элементов сети NGN. В основе таких решений для транспортной сети NGN, сети доступа NGN и существующих сетей (телефонной, передачи данных, телематических служб) лежат подсистемы контроля непрерывности линий связи, контроля параметров процессов и качества передачи информации, контроля каналов передачи информации и контроля качества услуг (рис.9.10).
190
Рис. 9.10 – Архитектура подсистемы контроля качества услуг NGN
Использование таких специализированных подсистем в сочетании с автономными средствами контроля, обеспечивающими в настоящее время возможность удаленного управления процессами измерений, позволяет подойти
к вопросу создания системы контроля сквозного качества услуг в сети NGN
путем их объединения в единую систему контроля (рис. 9.10).
Таким образом, решение задачи комплексного контроля сквозного качества услуг в сети NGN возможно путем объединения специализированных
подсистем и автономных средств контроля в единую интегрированную систему контроля.
В основе построения такой системы лежит приведенное выше комплексирование параметров контроля, согласно которому производится выбор
подсистем контроля параметров сети NGN, а собственно методология контроля базируется на распараллеливании процессов измерения, анализа, тестирования и мониторинга с представлением результатов контроля согласно
текущей задаче контроля качества услуг QoS. Так, в режиме наблюдения за
услугами оператору сети NGN предоставляются сетевые показатели, а также
интегральные и обобщенные параметры качества услуг QoS, в режиме обнаружения отказов в предоставлении услуг – весь спектр сетевых параметров,
связанных с возможным источником возникшей неисправности, а в режиме
диагностирования нарушений в процессе предоставления услуг – обеспечивается возможность просмотра сетевых параметров, вплоть до непрерывности линии связи.
191
Рис. 9.11 – Единая система контроля сквозного качества услуг в
сети NGN
Система контроля сквозного качества услуг NGN должна предоставлять следующие возможности для управления качеством услуг и уровнем обслуживания клиентов (сustomer QoS/SLA handling):
 создавать и контролировать параметры QoS/SLA;
 получать отчеты по соблюдению SLA и QoS в режиме on-line и за
определенный период;
 вести детальный анализ качества работы сети NGN;
 оповещать персонал при нарушении параметров QoS/SLA;
 выполнять расширенные тесты для VoIP (H.323, MGCP, MOS, NCS,
RTP, SCCP, SIP);
 выполнять расширенные тесты для Video и Voice (H.323, RTP,
RTSP);
 выполнять расширенные тесты для VPN;
 предоставлять возможность одновременно активных тестов (эмуляция трафика) и пассивных (контроль проходящего трафика).
При выборе архитектуры системы контроля качества услуг в сети NGN
должна учитываться возможность внесения в нее необходимых изменений за
счет использования открытой архитектуры. Такая архитектура контроля
услуг NGN должна основываться на открытых программных интерфейсах
OSA/Parlay и соответствующих специализированных приложениях. Это позволит обеспечить наиболее полное решение задач сквозного контроля качества предоставляемых услуг в сети NGN. Кроме этого такой подход позволит
в перспективе расширить область контроля при введении новых услуг NGN.
В сети NGN необходимо использовать новую технологию измерений
качества предоставления услуг QoS на верхних уровнях протоколов. В основе идеологии измерений должны использоваться принципы «эталонного
192
пользователя» и «эталонного приложения». Такая идеология оправдана тем,
что в большинстве случаев пользователь жалуется не на качество передачи
пакетов по сети оператора, а именно на качество услуг. В большинстве случаев под понятием «пропускная способность» пользователь понимает не ширину полосы пропускания в сети, а скорость обмена данными, задержка понимается как задержка ответа сервера, а количество ошибок – как количество
попыток скачать файл с какого-то сервера. Именно поэтому, проблема измерения качества услуг сети NGN должна рассматриваться с субъективной точки зрения.
При проведении измерений в сети NGN необходимо обеспечить не
только функции имитации работы пользователей или различных услуг, но и
функции контроля производительности приложений и сети в целом. При
этом должны совмещаться режим корректной работы имитируемого пользователя и услуги с высокой интенсивностью трафиковой имитации. За счет
этого можно выявить не только логические неисправности в предоставлении
услуг, но и найти слабые места в работе любого приложения.
9.3 Техобслуживание и техэксплуатация сетей NGN
Решения NGN порождают существенно более динамичные сетевые
инфраструктуры, чем традиционные сети с коммутацией каналов. При миграции
к
сетям
пакетной
коммутации
информационнотелекоммуникационные инфраструктуры становятся универсальными средами передачи произвольного трафика. Операторы такой инфраструктуры осознают необходимость корреляции информации о состоянии сетевых ресурсов
и процессов их модернизации, а также синхронизации процессов информационного взаимодействия между системами поддержки операций/системами
поддержки бизнеса OSS-BSS (Operations Support Systems/Business Support
Systems).
Постоянные изменения на сетевом уровне, как конфигурации топологии сети, так и структуры активного оборудования, требуют двусторонних
взаимодействий между всеми подсистемами автоматизации для обновления
циркулирующей информации, ее синхронизации в режиме, максимально
приближенном к реальному времени.
В настоящее время в состав системы поддержки эксплуатации сетей
связи OSS (Operation Support System) входят следующие основные компоненты (рис. 9.12):
193
Посредничество
Базопасность
Предоставление
услуг
Инвентаризация
Производительность
OSS
Управление
заказами
Ошибки
Учет
неисправностей
Управление
безопасностью
Ведение
учета
Управление
SLA
Рис. 9.12 – Состав системы поддержки эксплуатации сетей связи OSS
 средства взаимодействия (mediation) – обеспечивают сопряжение систем OSS/BSS с разнородным оборудованием различных производителей;
 управление инвентаризацией (Resource/Inventory Management) – отвечает за учет физических и логических ресурсов сети;
 управление производительностью (Performance Management) – осуществляет мониторинг параметров сети и анализ ее производительности;
 управление неисправностями (Fault Management) – представляет собой систему контроля и управления аварийными сигналами, которая
предназначена для их фильтрации и корреляции с целью выявления
первопричины, породившей поток взаимосвязанных аварийных сообщений;
 контроль выполнения задач по устранению неисправностей (Trouble
Ticketing);
 управление качеством предоставляемых услуг (SLA Management) –
обеспечивает оперативный мониторинг сервисов, доступных внутренним и внешним пользователям;
 управление нарядами на активацию услуг (Order Management) –
необходимо для отслеживания всех этапов исполнения заказа на
предоставление услуги;
 системы предупреждения мошенничества (Fraud Management) –
предназначены для пресечения и упреждения случаев несанкционированного и неоплаченного использования услуг операторов связи;
 модуль планирования и развития услуг (Service Provisioning
Management) – позволяет прогнозировать развитие событий и моделировать разнообразные сценарии;
194
 управление безопасностью (Security Management) – обеспечивает
контроль доступа к ресурсам сети;
 модуль учета (Accounting Management) – регистрирует время использования различных ресурсов сети.
С внедрением технологий NGN неизбежно возникает новая концепция
сетевой эксплуатации – концепция обеспечения гарантированного качества
услуг (Service Assurance). С одной стороны, она основана на системе поддержки эксплуатации сетей связи OSS, с другой – непосредственно связана с
услугами. Цель подсистем Service Assurance – обеспечить контроль качества
в сети NGN и выполнить любые требования заказчика к качеству предоставляемой услуги.
Успех в конкурентной борьбе будет определяться именно готовностью
оператора сети NGN предоставлять любые услуги связи, с одновременной
гарантией их качества. И дело не ограничивается только контролем над выполнением соглашений об уровне качества услуг SLA (Service Level
Agreement). В концепции Service Assurance понятие контроля качества
намного сложнее. Обусловлено это тем, что сеть NGN является разнородной
(этого требует сама специфика NGN), она состоит из отдельных компонентов, технологий, описываемых разными метриками параметров качества.
Пример многоуровневого контроля качества для услуги IPTV показан на рис.
9.13.
Рис. 9.13 – Многоуровневый контроль качества на примере услуги IPTV
Гарантировать определенные параметры качества по совокупности таких разнородных подсистем достаточно сложно. Таким образом, особенность
систем Service Assurance заключается в том, что при всей их привлекательности, они не могут существовать без тщательного контроля над всеми компонентами сети и управления ими. Эта задача по силам только централизованной системе эксплуатации на основе системы OSS. Следовательно, без реализации концепции OSS функционирование систем Service Assurance невозможно.
В состав сетей NGN должны входить мощные и гибкие системы управления сетями, реализованные в соответствии с концепцией TMN, стандартами форума TMF, базирующиеся на открытых интерфейсах типа OSA/Parlay.
Данные системы должны обеспечивать:
195
 возможность управления как гомогенными структурами, содержащими оборудование только одной фирмы, так и гетерогенными сетями,
включающими
оборудование
нескольких
фирмпроизводителей;
 управление типовыми фрагментами сети с одного рабочего места
управления сетью (РМУС), состоящего из одной или нескольких рабочих станций, объединенных ЛВС типа Ethernet- 10/100 Base T;
 в гетерогенной сети возможности управления оборудованием каждой
из фирм их собственными системами локального управления, расположенными на РМУС;
 объединение программ-менеджеров с использованием открытых интерфейсов;
 взаимодействие менеджеров системы управления с агентами, находящимися на сетевых элементах, по выделенным каналам управления для каждой системы управления.
В сетях NGN преобладающим станет подход к заданию уровня обслуживания на основании требований самих абонентов к качеству услуг. С учетом этих требований оператор сети NGN должен формировать исходные параметры, определяющие нужный уровень качества услуг. Параметры гарантированного качества услуг должны быть описаны для каждого приложения
и для разных уровней обслуживания.
Система управления должна позволять сторонним поставщикам услуг
быстро создавать и настраивать под конкретного клиента информационные
виды данных о функционировании каждой используемой им услуги. Поставщик услуг определяет содержание и формат этой информации таким образом, чтобы гарантировать максимальное удобство при ее просмотре. Кроме
того, благодаря открытым интерфейсам можно разрабатывать модули для
фирменных решений, которые также будут интегрированы в единую систему
управления сетью NGN.
Система управления сетью NGN должна иметь специализированный
шлюз, который позволит программно интегрировать приложение с существующей системой OSS сети NGN. Для этих целей используется прикладной
программный интерфейс API для создания индивидуальных SLA, извлечения
данных о сетевых характеристиках и выполнения тестов по контролю параметров услуг. Шлюз предназначен для автоматического создания параметров
уровня обслуживания для каждого включенного в систему клиента и автоматического отслеживания клиента и его тестирования в своей системе инвентаризационного контроля.
Кроме того, он используется для создания сообщений о превышении
заданных в SLA порогов, передачи в систему планирования сети хронологической информации, управления алгоритмами маршрутизации, основанными
на сетевых характеристиках в реальном масштабе времени и передачи данных в биллинговую систему по несоблюдению SLA.
Для успешной работы сети NGN необходима такая модель бизнеса, в
которой клиенты будут сами выбирать уровень качества обслуживания (QoS)
196
и соответственно его оплачивать. Критическим фактором станет способность
провайдера услуг обеспечить заданное, т.е. ожидаемое пользователем или
указанное в договоре с ним, качество обслуживания. Для реализации этой
концепции необходима интегрированная система сквозного управления сетью NGN по всем ее уровням – от сетевых элементов до услуг и приложений.
В соответствии с основными функциями техэксплуатации сети NGN
архитектура подсистемы OSS включает три основных подсистемы
(рис.11.13):
 подсистема управления оборудованием сети NGN;
 подсистема управления услугами сети NGN;
 подсистема обеспечения качества услуг сети NGN.
Подсистема управления оборудованием сети NGN предоставляет
весь спектр решений для планирования, проектирования, реализации и обслуживания сети NGN и позволяет оператору быстро устанавливать новое
оборудование, активировать новые функции сетевых устройств (NE) и
управлять их работой. Она обеспечивает активацию услуг передачи данных
уровней 2 и 3, которое автоматизирует сквозное конфигурирование услуг
ATM, IP и хDSL.
Подсистема автоматически устанавливает наиболее эффективные логические соединения в сетевой инфраструктуре и позволяет быстро и надежно разрабатывать новые услуги для корпоративных и частных клиентов с использованием технологий сети NGN.
Рис. 9.14 – Архитектура системы управления сетью NGN
197
Подсистема управления услугами занимается сбором информации
об использовании ресурсов во время процесса конфигурирования услуг. Она
отслеживает состояние заказов и обеспечивает сбор статистики, например, по
длительности выполнения задач. Она функционирует совместно с менеджером сетевых ресурсов. Редактор рабочих процессов позволяет модифицировать процесс конфигурирования услуг в соответствии с изменяющимися потребностями бизнеса. Подсистема управления услугами помогает снизить
стоимость создания, активации и реализации сетевых услуг (ATM и хDSL,
интеграция IP-услуг следующего поколения, создание сетей VPN).
Кроме этого, прикладные программы анализа и конфигурирования позволяют быстро, точно и своевременно обнаруживать и ликвидировать проблемы в сети.
Масштабируемая архитектура позволяет одновременно управлять
большим числом активаторов и поддерживать новые домены, оборудование
и технологии, появляющиеся по мере развития сети NGN. Подсистема должна поддерживать заявки на сетевые услуги, охватывающие множество технологий, включая xDSL, ATM/FR, SDH, PDH, Ethernet, IP, мобильную связь и
др. Типовая архитектура подсистемы управления услугами в сети NGN показана на рис. 9.15.
Рис. 9.15 – Типовая архитектура подсистемы управления услугами NGN
Подсистема обеспечения качества реализует предупредительный контроль услуг путем корреляции, измерений и статистического анализа и получения отчетов по сервисным договорам (SLA). Наличие интерфейсов API дает оператору возможность добавлять новые сетевые элементы и обеспечивает
взаимодействие с другими системами. Программные среды, такие как J2EE,
XML и .NET, на сегодняшний день хорошо развиты и широко используются
198
в архитектуре OSS-приложений. Архитектуры OSS, основанные на объектноориентированных компонентах, позволяют операторам быстро адаптироваться на динамически изменяющемся рынке телекоммуникационных услуг.
9.4 Контрольные вопросы к разделу 9
1.
2.
В чем особенность функциональной архитектуры сети NGN?
Какие функции выполняет транспортный уровень сети следующего
поколения?
3. Какие показатели качества услуг обеспечивает оператор связи?
4. Какую информацию получает оператор связи в режиме наблюдения
за качеством услуг?
5. Какие возможности предоставляет система сквозного контроля качества услуг NGN?
6. Каковы особенности системы технического обслуживания и эксплуатации NGN?
7. В чем особенности системы OSS для сетей связи следующего поколения?
Учебная литература
Основная литература
1. Ваняшин С.В. Конспект лекций по учебной дисциплине «Телекоммуникационный менеджмент».– Самара.: Изд. ФГОБУ ВПО ПГУТИ,
2012.– 321 с.
Дополнительная литература
2. Гребешков А.Ю. Управление сетями связи по стандартам TMN:
учебное пособие для студентов вузов.– М.: Радио и связь, 2004 г. –
155 с.
3. Гребешков А.Ю. Стандарты и технологии управления сетями электросвязи.  М.: ЭкоТрендз, 2003.–288 с.
4. Проектирование и техническая эксплуатация цифровых телекоммуникационных систем и сетей: учебное пособие для студентов вузов/
Е.Б. Алексеев, В.Н. Гордиенко, В.В. Крухмалев, А.Д. Моченов,
М.С. Тверецкий; под ред. В.Н Гордиенко и М.С. Тверецкого.– М.:
Горячая линия – Телеком, 2014. – 392 с.
199
200
Документ
Категория
Без категории
Просмотров
37
Размер файла
2 600 Кб
Теги
grebeshkov, posobie, ekspluatacii, uchebnoy, setyam, upravlenie, tehnicheskaya, sistemami, telekommunikacionnymi
1/--страниц
Пожаловаться на содержимое документа