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].

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

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

- функция 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, если требуется регистрация данного типа аварийной ситуации, или О, если такая регистрация не обязательна.

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

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

Сбор данных о рабочих характеристиках системы

Он связан как правило с определением параметров ошибок, описанных в рекомендации ITU-T Rес. G.826 [75]. При их определении используются следующие ключевые термины (см. подробно [75]):

- ЕВ - блок с ошибками;

- ES - секунда с ошибками;

- SES - секунда с серьезными ошибками;

- CSES - последовательные секунды с серьезными ошибками.

В основном используются следующие параметры ошибок (отнесенные к неискаженному интервалу измерения параметров): коэффициент ошибок по секундам с ошибками ESR, коэффициент ошибок по секундам с серьезными ошибками SESR, коэффициент ошибок по блокам с фоновыми ошибками BBER (здесь под блоками с фоновыми ошибками ВВЕ понимаются те блоки с ошибками, что не вошли в SES).

Отслеживание истории мониторинга рабочих характеристик

Отслеживание истории осуществляется заполнением двух типов регистровых файлов: 24-часовыми файлами и 15-минутными файлами. Текущий 24-часовой регистровый файл по заполнении снабжается текущей датой и перегружается в регистровый файл со вчерашней датой. Шестнадцать 15-минутных регистровых файлов образуют 4-часовую очередь с дисциплиной обслуживания "первый на входе - первый на выходе" FIFO.

Использование временных окон

Общая стратегия их использования описана в рекомендациях ITU-T Rес. М.20, М.2100, М.2120 [76-78]. В нашем случае с помощью OS в NE можно установить либо 15-минутное, либо 24-часовое временное окно. Как только время наступления события совпадает или выходит за границу установленного окна, генерируется уведомление о пересечении (временной) границы или порога TCN.

Генерация отчетов о характеристиках системы

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

Мониторинг системы в недоступные интервалы времени

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

Мониторинг дополнительных параметров

Дополнительные параметры, такие как:

- секунда, содержащая сигнал OOF (выход за границы фрейма) - OFS,

- число защитных переключений - PSC,

- длительность (определенного) защитного переключения - PSD,

- недоступные секунды - UAS.

Факт выравнивания указателя административного блока - AU PJE, а также CSES могут быть полезны для управления, однако их мониторинг не обязателен. Если он осуществляется, то для накопления предыстории указанных параметров (кроме CSES) используются регистровые файлы с 15-минутными или 24-часовыми временными окнами таким образом, как описано выше. Для параметра AU PJE отдельно должны фиксироваться как положительные, так и отрицательные PJE для одного выбранного AU внутри STM-N.

Событие CSES наступает тогда, когда обнаруживается последовательность из X или больше SES. При обнаружении этого события последовательность прерывается фиксацией начала недоступного интервала времени, в течение которого CSES не регистрируются. Конец этого интервала фиксируется тогда, когда регистрируется секунда не являющаяся SES. По крайней мере 6 CSES (вместе с датами появления первых SES в последовательности) должны при этом запоминаться. Значение X устанавливается OS в диапазоне от 2 до 9 в процессе ее конфигурации.

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

Статус и защитное переключение

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

- включение/выключение ручного режима защитного переключения,

- включение/выключение принудительного режима защитного переключения,

- включение/выключение блокировки,

- запрос/установка параметров автоматического защитного переключения - APS.

Другие функции

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

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

В рамках TMN подсеть SMS является локальной сетью связи LCN. Связь между SMS и OS может осуществляться через одну или более сетей передачи данных DCN и LCN. Это требует организации взаимодействия между SMS и либо DCN, либо LCN, также как и между DCN и LCN. Ниже кратко рассмотрено только взаимодействие между SMS и DCN. Взаимодействие между сетями невозможно без протоколов преобразования формата сообщений на интерфейсных стыках, которыми обмениваются сети, причем будут рассмотрены только протоколы так или иначе связанные с каналами DCC.

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

Для осуществления функций эксплуатации, администрирования, обслуживания и обеспечения ОАМ&Р при передаче сообщений в сетях SDH по каналам передачи данных (DCC) необходимо использовать набор, или стек, протоколов, ориентированный на эталонную модель взаимодействия открытых систем OSI.

Ниже приведен список уровней OSI и соответствующих им протоколов, выбранных для обслуживания встроенных каналов управления (ЕСС) сетей SDH.

Физический уровень - Протокол DCC не оговорен. DCC представляет физический уровень, причем DCC регенераторной секции работает для передачи сообщений как канал 192 кбит/с (байты SOH D1-D3), a DCC мультиплексной секции - как канал 576 кбит/с (байты SOH D4-D12).

Уровень звена данных - Протокол LAPD (Q.921, [79]). Обеспечивает через DCC сети SDH связь (канальный уровень) "точка-точка" между каждой парой смежных сетевых узлов. Используются два типа сервиса: передача информации с подтверждением приема AITS (спецификация этого типа сервиса приведена в [23, табл.6-3] и основана на рекомендации ITU-T Rec. Q.921; используется по умолчанию), передача информации без подтверждения приема UITS (спецификация этого типа сервиса приведена в [23, табл.6-2] и основана на рекомендациях ITU-T Rec. Q.921, 0.922 и ISO 8473 [79-81]).

Сетевой уровень - В соответствии с рекомендацией ITU-T Rec. Q.811 [73] используется протокол ISO 8473 [81]. Он обеспечивает дейтаграммный (т.е. не ориентированный на установление предварительного соединения) сервис, удобный для высококачественных высокоскоростных сетей. Этот же стандарт [81] определяет протоколы сведения, используемые для передачи как по ориентированным, так и по не ориентированным на установление соединения подсетям на уровне звена данных, для чего используется функция качества обслуживания QOS. Ее параметры определяются протоколом ISO 8473 и относятся к компетенции сетевого оператора.

Транспортный уровень - Требуемый транспортный протокол - протокол класса 4, обеспечивающий в соответствии с рекомендацией ITU-T Rес. Q.812 [74] надежную доставку по сети и транспорт не ориентированного на установление соединения низлежащего сетевого сервиса (см. стандарт ISO 8073/AD2 [82]), осуществляемые на уровне звена данных как через ориентированные, так и через не ориентированные на установление соединения подсети.

Сеансовый уровень - Используется сеансовый протокол, в соответствии с рекомендацией ITU-T Rec. Q.812 [74] обеспечивающий синхронизацию взаимодействующих систем связи при диалоге и управляющий, с учетом требований двух верхних уровней, запросами на транспортные соединения.

Уровень представлений - Используется протокол представлений, в соответствии с рекомендацией ITU-T Rec. Q.812 [74]. Этот уровень и нотация абстрактного синтаксиса ASN.1 должны обеспечивать возможность понимания как контекста, так и синтаксиса информации, передаваемой с прикладного уровня на низлежащие уровни.

Прикладной уровень - Используется протокол CMIP (см. стандарт ISO 9596 [83]). Поддержка протокола передачи файла, доступа и менеджмента FТАМ не требуется. В рамках CMIP используются следующие опции:

- сервисный элемент общей управляющей информации CMISE,

- сервисный элемент дистанционных операций ROSE,

- сервисный элемент ассоциированного управления ACSE

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

Каналы DCC регенераторных и мультиплексных секций используют сетевой протокол без установления соединения CLNP, описанный в ISO 8473 [81]. Связь в сети DCN между OS и SMS также базируется на основе протоколов OSI. Используется сетевой протокол с установлением соединения CONP технологии Х.25, описанный в стандарте ISO 8208 [84], с протоколом IP в качестве одной из опций в OS.

Согласно модели OSI взаимодействие между подсетями SMS и DCN должно происходить на сетевом уровне, тогда как транспортный и более высокие уровни используются для взаимодействия между конечными системами, например, SNE и OS. Сетевой уровень, в соответствии со стандартом ISO 7498 [85], должен быть прозрачен для потока данных между конечными системами, т.е. поток данных обрабатывается функциями маршрутизации и ретрансляции сетевого уровня и может зависеть только от качества сетевого сервиса различных подсетей. Взаимодействие подуровней сетевого уровня регламентируется стандартом ISO 8648 [86].

Взаимодействие между SMS и DCN

При передаче сообщений между SMS и DCN происходит взаимодействие между стеками протоколов CLNP (в SMS) и CONP (в DCN). На нижних уровнях OSI взаимодействие основано на стандарте ISO 10172 [87]. Стандарт ISO определяет функциональный блок взаимодействия IFU, который и осуществляет функцию ретрансляции и/или преобразование протокольных блоков данных PDU между сетями.

Ретрансляция на сетевом уровне

Блок IFU, функционирующий в режиме ретрансляции на сетевом уровне (NLR), является регулярной промежуточной системой и представляет единственный удовлетворяющий OSI метод взаимодействия между конечными системами, имеющими различные сетевые протоколы. Под взаимодействием понимается функция сетевого уровня, определенная стандартами ISO 7498 и ISO 8648 [85,86]).

Правила функционирования CLNP на сети пакетной коммутации (PSN) X.25, определяются функцией сведения, зависящей от подсети (SNDCF), описанной в стандарте ISO 8473 [81].

Режим NLR может обеспечить взаимодействие между SMN и DCN, если обе сети используют протокол CLNP и соединение типа ТР Class 4 (ТР4). В этом случае сетевой сервис верхнего уровня SMS SNE - DCN OS играет роль сервиса, соответствующего режиму взаимодействия без установления соединения на сети Х.25, обеспечивающей (через сеть DCN с протоколом CONP) взаимодействие IFU с OS. При этом IFU анализирует адреса назначения сетевых протокольных блоков данных NPDU, полученных от SMN, и транслирует соответствующие CLNP NPDU от SMS на коммутируемые виртуальные цепи SVC Х.25 сети DCN.

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

Из всех интерфейсов, взаимодействующих с сетью TMN (рис.3-2), здесь будут рассмотрены только два интерфейса Q и F, которые являются внутренними интерфейсами сети TMN. Наиболее важным из них безусловно является группа интерфейсов, объединенных общим названием Q-интерфейс.

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

Для взаимодействия с сетью TMN, SMS использует Q-интерфейс (рекомендация ССIТТ G.771 [88]), имеющий три набора или стека протоколов: В1, В2, ВЗ, определенных в рекомендации ITU-T G.773 [89, версия 1990г.]. Эти стеки протоколов были позднее заменены на стеки: А1, А2 - короткий стек и CONS1, CLNS1, CLNS2 (вместо В1, В2, ВЗ соответственно) - полный стек, определенный в рекомендации G.773 [89, версия 1993г.]. В этой последней публикации описаны только стеки А1 и А2, которые в основном соответствуют интерфейсу Q_x, причем выбор соответствующего стека остается за производителем оборудования. Профиль протоколов CONS1, CLNS1 и CLNS2 для уровней 1-3 модели OSI описан в рекомендации ITU-T Q.811 [73], а для уровней 4-7 - в ITU-T Q.812 [74]. Они соответствуют как интерфейсу Qз, так и Q_x (при необходимости реализации всех уровней модели OSI) сетей SDH.

Короткие стеки протоколов А1 и А2 представлены в таб.3-2.

Для уровней 4-6 модели OSI протоколы и отображающие функции не регламентируются. Более подробно это рассмотрено в рекомендации G.773 [89, версия 1993 г.].

Скорости передачи, поддерживаемые интерфейсом Q_x, зависят от стека протоколов. Для А1 они равны 19200 и 64000 бит/с, хотя можно использовать и 128 кбит/с. Для А2 она равна 1 Мбит/с или выше.

На рис.3-11 приведена модель сети DCN [73], на которой белые кружочки на концах линий показывают положение интерфейсов Q₃, соединительные линии между ними - маршруты связи между выделенными точками, а двухбуквенный код ab указывает типы сетей, подключенных к интерфейсам и вовлеченных во взаимодействие. Буква a указывает на сеть, с которой данный интерфейс физически соединен, а буква b - на сеть, с которой соединен другой, взаимодействующий с ним, интерфейс. Например, код интерфейса ga (интерфейс показан у левого верхнего блока CLNS X.25) говорит, что данный интерфейс соединен с сетью CLNS/X.25 (буква g соответствует сети с пакетной коммутацией Х.25, тип сервиса CLNS, см. расшифровку под рисунком) и через сеть DCN по маршруту gа - аg связан с интерфейсом аg, соединенным с сетью PSPDN (буква a соответствует сети передачи данных общего пользования с пакетной коммутацией PSPDN, тип сервиса CONS).

Рис.3-11. Модель сети DCN с маршрутами связи интерфейсов Q₃

Пояснения к рис.3-11.

- К интерфейсам Q₃ могут подключаться OS, MD, QA и NE (на рис. не показаны).

- Черными кружочками показаны опорные точки блоков взаимодействия IWU.

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

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

Сеть DCN разбита по типу сервиса на две части: сеть, использующая режим без установления соединений (CLM) - CLNS и сеть, использующая режим установления соединений (СМ) - CONS. При этом используются следующие профили протоколов нижних трех уровней:

CONS1 - пакетный интерфейс, использующий протокол Х.25 с режимом установления соединений, применим к опорной точке между PSPDN и OS/MD/QA/NE;

CONS2 - пакетный интерфейс, использующий протокол Х.31 с режимом установления соединений на D-канале ISDN, применим к опорной точке между ISDN и OS/MD/QA/NE;

CONS3 - пакетный интерфейс, использующий протокол Х.31 с режимом установления соединений на В-канале ISDN, применим к опорной точке между ISDN и OS/MD/QA/NE;

CONS5 - интерфейс, использующий протоколы системы сигнализации SS#7 MTP и SS#7 SCCP с режимом установления соединений;

CONS6 - пакетный интерфейс, использующий протокол Х.25 с режимом установления соединений через локальную сеть, применим к OS/MD/QA/NE, подключаемым к LAN;

CLNS1 - интерфейс, использующий локальные сети Ethernet с протоколом типа ISO 8802-2 и режимом без установления соединений, применим к опорной точке между LAN и OS/MD/QA/NE;

CLNS2 - интерфейс с режимом без установления соединений, использующий IP протокол на сети Х.25 с режимом установления соединений, применим к опорной точке между PSPDN и OS/MD/QA/NE.

Более подробно стеки протоколов для указанных интерфейсов описаны в [73].

Скорости передачи, поддерживаемые интерфейсом Q₃, зависят от типа CLNS. Для CLNS1 она составляет 1,10 Мбит/с или выше. Для CLNS2 соответствуют ряду: 1200, 2400, 4800, 9600, 19200 и 64000 бит/с (допустимо в течение некоторого переходного периода использование скоростей 48000 и 56000 бит/с).

Для CLNS1 в качестве физической среды распространения сигнала используют коаксиальный кабель, экранированную витую пару или ВОК. Для CLNS2 в качестве соединительных разъемов допустимо использовать те, что поддерживают интерфейсные протоколы Х.21, X.21bis и интерфейсы серии V. К этим интерфейсам из широко известных относятся Х.21 и V.35 и из не очень широко известных ISO 2110 (Х.21 bis), ISO 2593 (Х.21, Х.21 bis), ISO 4902 (X.21bis) и ISO 4903 (Х.21) [104,105]. Описание сигналов на контактах и их соответствие сигналам интерфейсов Х.21 и Х.21 bis также приведены в рекомендации ITU-T Q.811 [73].

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

Согласно общей концепции, местоположение интерфейса F соответствует положению опорных точек f. Как было указано выше, через интерфейс F сеть DCN связана с рабочей станцией WS - монитором управляющей системы. Благодаря этой связи обеспечивается выполнение функций OSF и MF, осуществляющих, как было описано выше, ряд управляющих действий, например:

- общую обработку управляющей информации,

- реализацию функции управляющего приложения OSF-MAF,

- обработку информации, передаваемой между блоками OSF и NEF (или QAF),

- реализацию функции управляющего приложения MF-MAF.

Возможностей управления сетью через интерфейс F со стороны диспетчера сети, сидящего за дисплейным пультом управления WS, достаточно много даже на уровне основных функций управления, включающих (раздел 3.3.2) общие функции управления, управление потоками сообщений о возникновении аварийных ситуаций, управление рабочими характеристиками оборудования, управление конфигурацией, управление выставлением счетов, обеспечение надежности и сохранение безопасности функционирования системы, а также ее тестирование. Более подробно эти возможности перечислены в Приложении А к рекомендации ITU-T М.3300 [66].