3.3. Общая схема управления сетью SDH

3.3.1. Подсеть SMS сети управления SMN

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

3.3.2.1. Общие функции управления

3.3.2.2. Управление сообщениями об аварийных ситуациях

3.3.2.3. Управление рабочими характеристиками

3.3.2.4. Управление конфигурацией

3.3.3. Протоколы и внутрисистемные взаимодействия

3.3.3.1. Обзор используемых протоколов

3.3.3.2. Внутрисистемные взаимодействия

3.3.4. Интерфейсы взаимодействия

3.3.4.1. Q-интерфейс

3.3.4.2. F-интерфейс

В свете вышесказанного, рассмотрим более подробно схему управления сетью SDH. Схема организационного управления сетью (рис.3-9) многоуровневая [23]. Нижний уровень этой схемы включает SDH NE, которые обеспечивают транспортный сервис. Функции MAF внутри них осуществляют связь с одноранговыми NE и поддержку управления ими, а также устройствами MD и управляющей системой OS.

На схеме используются следующие обозначения:

MCF — функция передачи сообщения А — агент

MAF — функция управляющего приложения М — менеджер

NEF — функция сетевого элемента МО — управляемый объект

ЕСС — встроенный канал управления F, Q – интерфейсы

Нижний уровень состоит из трех сетевых элементов и в целом напоминает рис.3-86 (два нижних блока). В каждом элементе логически выделены три функции: MCF, MAF и NEF, причем MAF каждого элемента может включать Агент или Менеджер или их оба. Управляющее сообщение, поступающее по ЕСС через интерфейсы F и Q или от элемента другой (не SDH) сети, передается с помощью MCF, затем интерпретируется с помощью MAF и через Агента, интерпретирующего NEF, передается на управляемый объект МО. Реакция объекта передается обратно через Агента и Менеджера в канал ЕСС, или через интерфейсы F и Q на средний уровень — MD, взаимодействующий непосредственно с OS, которая управляется от ЕМ или NMS. Формат сообщений в такой многоуровневой структуре поддерживается одинаковым, как при движении по горизонтали — NE-NE, так и по вертикали: NE-MD, MD-OS.

3.3.1. Подсеть SMS сети управления SMN

Сеть управления SDH (SMN), будучи сама составной частью TMN, состоит из нескольких подсетей SMS. Архитектура SMS и их взаимодействие с TMN приведены на рис.3-10 [23].

blank

Отметим ряд особенностей этой архитектуры:

— несколько адресуемых NE могут располагаться в одном месте, доступ к которому осуществляется через шлюзовые элементы сети GNE, например GNEE – CNEG;

— функция MCF имеет возможность завершать, маршрутизировать или обрабатывать сообщения, передаваемые по ЕСС или через внешний Q-интерфейс;

— на основе ЕСС можно сформировать звено связи между офисами или местами установки оборудования;

— в пределах одного места установки оборудования можно организовать связь, используя либо встроенные каналы управления ЕСС, либо локальную сеть связи LCN.

Топология SMS и ЕСС

Каждая SMS должна иметь хотя бы один элемент, соединенный с MD или OS, он называется шлюзовым элементом сети GNE, так как служит шлюзом в подсеть SMS.

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

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

3.3.2.1. Общие функции управления

Управление каналами ЕСС. Так как ЕСС используются для связи NE, то каналы ЕСС должны иметь следующие функции:

— запрос/получение сетевых параметров, таких как размер пакета, временные промежутки, качество сервиса и т.д.;

— формирование маршрутизации сообщения между узлами DCC;

— менеджмент сетевых адресов (возможное преобразование форматов адресов);

— запрос/получение сетевого статуса DCC для данного узла;

— возможность разрешать/запрещать доступ к DCC.

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

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

3.3.2.2. Управление сообщениями об аварийных ситуациях

Наблюдение за сообщениями об аварийных ситуациях. Оно включает обнаружение таких сообщений и/фиксацию/сохранение сообщений о тех событиях и условиях, которые сопутствовали их появлению, причем не только в том оборудовании, в котором они были обнаружены. OS SMN должна поддерживать следующие функции:

— автономное сообщение о всех сигналах о возникновении аварийной ситуации;

— запрос на обобщение о всех зарегистрированных сигналах о возникновении аварийной ситуации;

— сообщение о всех таких сигналах;

— разрешение/запрет на автономное сообщение о всех сигналах о возникновении аварийной ситуации;

— сообщение о статусе функции «разрешение/запрет на автономное сообщение о всех подобных сигналах».

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

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

Основные типы сообщений о возникновении аварийной ситуации. Для того, чтобы получить более полное представление о типах аварийных ситуаций, которые отслеживаются в сети SDH, они представлены в виде таб.3-1 [23], где в левом столбце помещены типы аварийных ситуаций, а в верхней строке — места их возможного возникновения. В ячейках таблицы помещен символ R, если требуется регистрация данного типа аварийной ситуации, или О, если такая регистрация не обязательна.

blank

В таблице использованы следующие сокращения:

TF

Сбой при передаче

RS

Регенераторная секция

LOS

Потеря сигнала

MS

Мультиплексная секция

LOF

Потеря фрейма

Path HOVC

Маршрут VC верхнего уровня

LOP

Потеря указателя

Path LOVC

Маршрут VC нижнего уровня

FERF

Сбой при приеме на удаленном конце

PPI/LPA

Плезиохронный физический интерфейс/адаптация маршрута VC нижнего уровня

TIM

Несовпадение идентификатора трассировки

SLM

Несовпадение типа сигнала

SETS

Хронирующий источник оборудования

LOM

Потеря мультифрейма

AIS

Сигнал индикции аварийного состояния

R1

Для нагрузки, требующей индикации мультифрейма

Ехс

Слишком много ошибок

LTI

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

R2

Если подтверждается использование байта J2 в VC-11, VC-12 и VC-2

SD

Ухудшение качества сигнала

SPI

Физический интерфейс SDH

R3

Для байт-синхронного отображения

To top