Федеральное агентство связи


Рис. 6.3. Соотношение между функциями передачи данных DCF и сообщений MCF Внешний доступ к TMN



страница6/7
Дата22.06.2019
Размер1.12 Mb.
ТипКонспект
1   2   3   4   5   6   7

Рис. 6.3. Соотношение между функциями передачи данных DCF и сообщений MCF

Внешний доступ к TMN

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





Рис. 6.4. Типы и положение интерфейсов между блоками управляющих функций

6.2.2.2. Информационный аспект архитектуры

При создании информационной модели обмена данными (сообщениями) в TMN используется объектно-ориентированный подход (ООП) и концепция Менеджер/Агент.

ООП рассматривает управление обменом информацией в TMN в терминах Менеджер - Агент -Объекты. Менеджер (рис.6.5), представляя управляющую открытую систему, издает в процессе управления управляемой открытой системой директивы и получает в качестве обратной связи от объекта управления уведомления об их исполнении. Директивы, направленные от Менеджера к объекту, доводятся до объекта управления Агентом. Уведомления, направленные от объекта к Менед­жеру, доводятся до Менеджера тем же Агентом.



Рис. 6.5. Схема взаимодействия между Менеджером, Агентом и объектами

Один Менеджер может быть вовлечен в информационный обмен с несколькими Агентами и, наоборот, один Агент может взаимодействовать с несколькими Менеджерами. Агент может игнорировать директивы Менеджера по соображениям нарушения секретности доступа к объекту или другим причинам. Все взаимодействие между Менеджером и Агентом осуществляется на основе ис­пользования протокола общей управляющей информации CMIP и сервиса общей управляющей информации CMIS, описанных в рекомендациях ITU-T Rec. X.711 и ITU-T Rec. X.710.

Указанная схема взаимодействия может быть использована при организации связи и взаимо­действия между несколькими системами на основе TMN. На рис.6.6 показана схема взаимодействия трех каскадно связанных сетями TMN систем А, В и С, в которой система А управляет системой В, которая, в свою очередь, управляет системой С. Здесь Менеджер М системы А управляет системой В, ориентируясь на информационную модель системы В, которую он "видит" благодаря тому, что она хранится в базе MIB системы В и доступна для М через Агента А этой системы. На основе этой информации М, используя сервис CMIS и протокол CMIP организует движение вниз по стеку прото­колов OSI системы А от прикладного уровня до физического, на котором происходит связь со стеком протоколов OSI системы В, а затем движение по нему вверх с выходом через CMIS/CMIP на Агента системы А. Он реализует директиву от Менеджера М по управлению объектами (ресурсами) системы В, отображаемыми в MIB. По цепи обратной связи Менеджер М системы А получает уведомление от этого объекта через Агента системы В. По цепи прямой связи информация об изменении стату­са/состояния объекта (ресурса) отображается в MIB системы В и поступает Менеджеру М системы В, управляющему системой С. Алгоритм действий Менеджера М системы В аналогичен описанному для системы А. Ясно, что уведомление, получаемое Менеджером М системы В, передается далее в сис­тему А и производит изменение в MIB систем С и В.




Рис. 6.6. Пример связи и взаимодействия TMN систем

6.2.2.3. Общий аспект архитектуры TMN

Функциональный и информационный аспекты взаимодействия систем на основе TMN, кратко описан­ные выше, являются хорошей основой для рассмотрения общего аспекта или собственно архитектуры TMN. На рис.6.7 представлен простой пример такой архитектуры управления сетями, где функцио­нальные блоки представлены выполняющими только свои обязательные функции (NEF, MF, QAF, OSF, WSF для NE, MD, QA, OS и WS соответственно). Эти блоки могут выполнять и другие (необязательные) функции.





Рис. 6.7. Общая архитектура управления телекоммуникационными сетями

В этой схеме (рис.6.7) управляющая система OS взаимодействует с телекоммуникационными се­тями через три типа интерфейса, соответствующие опорным точкам: X, F, Q3. Взаимодействие осущест­вляется через сеть передачи данных DCN, реализующую протоколы уровней OSI 1-3 и поддерживаю­щую функцию DCF. DCN может состоять из нескольких связанных между собой подсетей различного типа. Например, это могут быть подсети, образованные каналами связи данных типа DCC в сетях SDH.

Через интерфейс F сеть DCN связана с рабочей станцией WS, играющей роль монитора управ­ляющей системы. Интерфейс X связывает DCN с "внешним миром", через интерфейс Q3 DCN может быть напрямую связана с сетевым элементом NE или с Q-адаптером QA, позволяющим подключать оборудование, имеющее несовместимые с TMN интерфейсы. Наконец, через интерфейсы Q3 и F сеть DCN подключается к устройствам сопряжения MD.

Устройства MD, в свою очередь, через интерфейс Qx подключаются к другим DCN или к подсе­тям той-же DCN, которые через интерфейсы Qx связаны напрямую с NE и QA.



Протоколы TMN

Кроме указанных выше протоколов CMIP, CMIS, существуют группы протоколов, поддерживаю­щих каждый из указанных выше интерфейсов: Q3> Qx, X и F. Выбор протокола зависит от требований по реализации данной физической конфигурации. Прикладной уровень (верхний уровень семиуров­невой модели взаимодействия открытых систем OSI/ISO) является общим для всех групп протоколов, причем он не всегда требуется. Для интерфейса Q3 на верхних уровнях (с 4 по 7) модели OSI исполь­зуются протоколы в соответствии с рекомендацией ITU-T Rec. Q.812, на нижних уровнях (с 1 по 3) - в соответствии с рекомендацией ITU-T Rec. Q.811. При этом первые три уровня требуются пра­ктически всегда, так как транспорт сообщений TMN осуществляется протоколами сетевого уровня.

Для оборудования, не имеющего такого интероперабельного интерфейса как Q-интерфейс, приходится конвертировать используемые протоколы и сообщения в формат соответствующего интер­операбельного интерфейса. Такая конвертация осуществляется MCF, а также QAF, которые могут быть реализованы в QA, NE, MD или OS.

Примеры реализации DCN

В сетях SDH, использующих концепцию Менеджер-Агент, взаимодействие DCN реализуется с использованием MCF. На рис.6.8а,б приведены два примера реализации таких сетей, обеспечиваю­щих функцию DCF в среде SDH. Объединяющий овал на рисунке указывает, что оба интерфейса имеют объединений транспорт.





Рис. 6.8а. Примеры TMN для управления сетью SDH



Рис. 6.8б. Примеры TMN для управления сетью SDH

В первом примере Менеджер управляющей системы OS, реализует функцию управляющего приложения OSF-MAF и управляет, используя интерфейс Q3 и встроенные каналы управления ЕСС, устройством сопряжения MD и элементами сети NE1 и NE2 через MCF. Кроме этого, через ин­терфейсы Q3 и Qx реализуется и стандартная для концепции Менеджер-Агент схема управления уст­ройствами MD, NE1 и управляемым объектом МО.

Во втором примере используется только эта стандартная схема управления всеми устройства­ми, поддержанная функцией MF-MAF и осуществляемая через интерфейсы Q3 и Qx.

Лекция 12.

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

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





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

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

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

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

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

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

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

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

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





Рис. 6.10. Архитектура подсетей SMS и взаимодействие SMS с TMN

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

Таблица 6.1. Основные типы сообщений об аварийных ситуациях, отслеживаемые в сети SDH

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

TF Сбой при передаче RS Регенераторная секция

LOS Потеря сигнала MS Мультиплексная секция

LOF Потеря фрейма Path HOVC Маршрут VC верхнего

LOP Потеря указателя уровня

FERF Сбой при приеме на удаленном конце Path LOVC Маршрут VC нижнего

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

SLM Несовпадение типа сигнала PPI/LPA Плезиохронный

LOM Потеря мультифрейма физический интерфейс/

AIS Сигнал индикации аварийного состояния адаптпция маршрута VC

Ехс Слишком много ошибок нижнего уровня

LTI Потеря синхронизации на входе SETS Хронирующий источник

SD Ухудшение качества сигнала синхронного оборудования

SPI Физический интерфейс SDH R1 Для нагрузки, требующей

индикации R3 мультифрейма

R2 Если подтверждается

использование байта J2

в VC-11, VC-12 и VC-2

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

отображения


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

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

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

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

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

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

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

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

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

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



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

Общая стратегия их использования описана в рекомендациях ITU-T Rec. M.20, М.2100, М.2120. В нашем случае с помощью 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 в процессе ее конфигурации.



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

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

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

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

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

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

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



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

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



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

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



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

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

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

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

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

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

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

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

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


Каталог: wp-content -> uploads -> 2013 -> ССТ
2013 -> Офис в Великобритании
2013 -> Методические указания по подготовке к защите выпускной квалификационной работы для студентов 4курса очной формы обучения по специальности 190604
2013 -> Руководство по применению строительных материалов ООО «стройдеталь»
2013 -> Консолидированный текст конвенции солас-74 consolidated text of the 1974 solas convention
2013 -> Ключевые слова: фармакологический аборт, менструальная функция, пенкрофтон, мизопростол. E. M. Pichushkina, S. B. Radynova, T. K. Paramonova analysis menstrual function in women with pharmacological abortion abstract
2013 -> Нэнси Мак-Вильямс
2013 -> Крок Лечебное дело и педиатрия. Буклет 2003 год
ССТ -> Учебное пособие по курсовому проектированию по курсу


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница