Управление сетью sdh

6. Управление сетью sdh.

Функционирование любой сети (и сети PDH и SDH/SONET не являются исключением) невозможно без ее обслуживания на различных уровнях. Обслуживание сети сводится в общем случае к автоматичес­кому, полуавтоматическому или ручному управлению системой, ее тестированию и сбору статистики о прохождении сигнала и возникающих неординарных или аварийных ситуациях, а также менеджмен­ту (или административному управлению системой). Эти функции в свою очередь невозможно осу­ществить без сигнализации различного рода о состояниях системы, например сигнализации о воз­никновении аварийного состояния. Сигнализация должна осуществляться по специальным встроен­ным или зарезервированным для этого каналам, связывающим управляющие (оперирующие на сети) системы OS и управляемые системы или сетевые элементы NE.

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

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

6.1. Четырехуровневая модель управления сетью

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

• бизнес-менеджмент (верхний уровень управления экономической эффективностью сети - BOS);

• сервис-менеджмент (уровень управления сервисом сети - SOS);

• сетевой менеджмент (уровень систем управления сетью - NOS);

Рекомендуемые материалы

• элемент-менеджмент (нижний уровень элемент-менеджеров ЕМ или систем управления элементами сети EOS).

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

Элемент-менеджер ЕМ осуществляет управлением отдельными элементами сети NE, т.е. оборудованием (мультиплексорами, коммутаторами, регенераторами и.т.д.) сети. Его задачи:

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

- мониторинг - определение степени работоспособности (статуса), сбор и обработка сигна­лов о возникновении аварийных ситуации (алармов - А), несущих информацию типа "в эле­менте сети NE_i произошла ошибка А_i";

- управление функцией передачи - управление операционными параметрами, отвечающи­ми за функционирование сети, а именно: проверка состояния интерфейсов, активация сис­тем защиты для переключения на резервное оборудование;

- управление функциями TMN - управление потоками сигналов о возникновении аварийных состояний, адресация возникающих при этом сообщений, формирование критериев фильт­рации ошибок, маршрутизация пакетов сообщений по служебным каналам, формируемым за счет SOH в фреймах SDH, генерация и мониторинг сигналов синхронизации;

- тестирование элементов сети - проведение тестов, характерных для данного типа обору­дования;

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

Функции ЕМ могут интерпретироваться как независимые функции OS, осуществляемые конкрет­ными NE с помощью данного ЕМ через сервисные интерфейсы, поддерживаемые данной OS. Для осуществления этих функций все NE должны быть известны и различаемы для конкретной OS. Если несколько OS реализуют одни и те же сервисные интерфейсы, то в этом случае функции элемент-менеджмента могут быть распределены по нескольким OS_i, как это показано ниже на рис.6.1.

Сетевой менеджер NM, или система управления сетью NMS, призваны управлять сетевым уровнем, или сетью в целом. На этом уровне менеджер абстрагируется от отдельных элементов сети, рассматриваемых с точки зрения выполнения задач, управляемых элемент-менеджером. Это не зна­чит, что NM их не видит, они рассматриваются здесь как элементы, поддерживающие сетевые связи - маршруты в терминологии SDH. NM использует следующие функции NE:

- функцию  связи,   осуществляемую   всеми  элементами,   имеющими   возможность   кросс-коммутации;

- функцию доступа к мультиплексору, осуществляемую всеми мультиплексорами;

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

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

Сетевой менеджер осуществляет следующие функции:

- мониторинг - проверка маршрута передачи с использованием функции проверки окончания маршрута,   проверка   качества   передачи   и   самой   возможности   связи,   при   этом   NE используются либо непосредственно самой OS, либо через операционную систему ЕМ;

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

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

Как и в любом слое NM обеспечивает маршруты для слоя SM.

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

- мониторинг   -   проверка   возможности   осуществления   сервиса,   а   также   доступности маршрутов передачи, подготовленных в слое NM;

- управление  -  управление характеристиками  сервиса,  а также формирование     запросов сетевому уровню на изменение маршрутов передачи;

- локализация в рамках выделенного слоя - осуществление сервиса SM  и обработка
информации от NM.

SM также обеспечивает информацию о новых  видах сервиса для слоя ВМ.

Бизнес-менеджер обеспечивает мониторинг и управление типами сервиса, а также фор­мирование запросов на уровень сервиса, лежащий ниже, на изменение вида сервиса.

6.2. Сеть управления телекоммуникациями TMN.

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

6.2.1. Концепция TMN и общая схема управления

Основная концепция TMN заключается в формировании такой архитектуры, которая позволит связать различные типы управляющих систем OS - EOS, NOS, SOS, как между собой, так и с элементами се­ти NE (сетевым оборудованием) для обмена управляющей информацией с помощью стандартных ин­терфейсов, протоколов и сообщений.

Общая схема управления телекоммуникационными сетями TCN с помощью сети управления TMN приведена на рис.6.1. Здесь OS_j могут быть связаны между собой через общую сеть пере­дачи данных DCN (управляемую рабочей станцией WS), которая также связывает их с различным аналоговым и цифровым телекоммуникационным оборудованием, объединенным в общую телеком­муникационную сеть TCN. Предполагается, что TMN будет поддерживать пять типов менеджмен­та и управления:

- управление рабочими характеристиками систем;

- управление отказами и обеспечение надежности работы систем;

- управление конфигурацией систем;

- менеджмент бухгалтерской отчетности и тарификации (биллинга) в системе;

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

6.2.2. Архитектура TMN

Архитектура TMN рассматривается в трех аспектах:

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

- информационном, основанном на объектно-ориентированном подходе и принципах OSI;

- физическом, описывающем реализуемые интерфейсы и примеры физических компонентов TMN.

6.2.2.1.Функциональные блоки и их компоненты

TMN включает ряд функциональных блоков, выполняющие следующие одноименные функции (в скоб­ках даны термины, используемые в русских переводах стандартов ITU-T):

OSF   - функции управляющей (операционной) системы OS;

MF     - функция устройств сопряжения М (медиаторная функция);

NEF   - функция сетевого элемента NE;

QAF    - функция Q-адаптера QA;

WSF   - функция рабочей станции WS.

Для передачи информации между указанными блоками TMN используется функция передачи данных DCF. Пары функциональных блоков, обменивающихся информацией, разделены между собой опорными (или интерфейсными) точками. Три из указанных блоков, выполняющих функции NEF, QAF и WSF, принадлежат TMN лишь частично (рис.6.2).

Рис.6.2. Типы и положение

интерфейсов в схеме управления сетью

Функциональные блоки не только выполняют указанные функции, но и содержат дополнитель­ные функциональные компоненты, реализующие определенные функции, а именно:

Блок OSF - обрабатывает управляющую информацию с целью мониторинга и/или управления, а также реализует функцию управляющего приложения OSF-MAF;

Блок MF    - обрабатывает информацию, передаваемую между блоками OSF и NEF (или QAF), позво­ляя запоминать, фильтровать, адаптировать и сжимать информацию, а также реализует функцию управляющего приложения MF-MAF;

Блок NEF  - включает функции связи, являющиеся объектом управления, а также реализует функцию управляющего приложения NEF-MAF;

Блок QAF - подключает к TMN логические объекты класса NEF или QSF, не являющиеся частью TMN, осуществляя связь между опорными точками внутри и вне TMN, а также реализует функ­цию управляющего приложения QAF-MAF;

Блок WSF - позволяет интерпретировать информацию TMN в терминах, понятных пользователю уп­равляющей информации.

Дополнительные функциональные компоненты, игравшие ранее самостоятельную роль в качес­тве блоков TMN, теперь включены в состав функциональных блоков. К ним относятся:

MAF   -    функция    управляющего    приложения    -    фактически    осуществляет    управляющий (административный) сервис TMN, может играть роль либо Менеджера, либо Агента , используется в функциональных блоках MF, NF, OSF и QSF (см. п.6.2.2.2);

MIB - база управляющей информации - играет роль репозитария (информационного архива) управляющих объектов, не является объектом стандартизации TMN, используется в схеме дистанционного мониторинга RMON, а также протоколом SNMP, применяется во всех, кроме WSF, функциональных блоках;

ICF     -    функция преобразования информации - используется в промежуточных системах для трансляции информационной модели с интерфейса на интерфейс, используется в функцио­нальных блоках MF, OSF, QAF;

PF      -    функция представления - преобразует информацию к удобному для отображения виду, используется в функциональном блоке WSF;

НМА   -    человеко-машинная адаптация - преобразует информацию MAF к удобному для отобра­жения виду, используется в функциональных блоках OSF, MF;

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

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

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

В сети TMN вводятся опорные (интерфейсные) точки, определяющие границы сервиса. Эти то­чки делятся на две группы. Первая - включает точки внутри TMN, вторая - вне её. Точки первой груп­пы делятся на три класса:

- q -   точки между блоками OSF, QAF, MF и NEF, обеспечивают информационный обмен между блоками в рамках информационной модели, описанной в стандарте ITU-T М.3100; эти точки делятся на два типа:

- q_x - точки между двумя блоками MF или блоком MF и остальными блоками;

-  q₃ - точки между двумя блоками OSF или блоком OSF и остальными блоками;

- f    - точки для подключения блоков WSF к OSF и/или к MF, подробнее описаны в рекомендации ITU-Т Rec. M.3300;

-  х   - точки между OSF, принадлежащих двум TMN.

Точки второй группы делятся на два класса:

-  g   - точки между WSF и пользователем (см. определение в стандарте ITU-T Rec. Z.300);

-  m - точки между QAF и управляемым объектом, не принадлежащим TMN.

В соответствии с положением указанных опорных точек определяется положение соответству­ющих им интерфейсов TMN, обозначаемых заглавными буквами. Оно показано на рис.6.2 и рис.6.4. Пунктиром на рис.6.2 отмечены границы TMN. В соответствии с ними интерфейсы Q и F явля­ются внутренними для TMN, интерфейс X - пограничным, а интерфейсы М и G - внешними.

Функция передачи данных DCF

Основная цель DCF - создать транспортный механизм для передачи информации между блока­ми, наделенными управляющими функциями (рис.6.3). В нашем случае это функции TMN блоков А и В. Характер взаимодействия между ними равноправный (одноранговый). Механизм взаимодействия осуществляется путем ретрансляции DCF на уровне OSI. Этот механизм может обеспечить все функ­ции, характерные для первых трех уровней модели OSI (физического, звена передачи данных и сете­вого), или их эквивалент.

Рис. 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, Q₃. Взаимодействие осущест­вляется через сеть передачи данных DCN, реализующую протоколы уровней OSI 1-3 и поддерживаю­щую функцию DCF. DCN может состоять из нескольких связанных между собой подсетей различного типа. Например, это могут быть подсети, образованные каналами связи данных типа DCC в сетях SDH.

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

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

Протоколы TMN

Кроме указанных выше протоколов CMIP, CMIS, существуют группы протоколов, поддерживаю­щих каждый из указанных выше интерфейсов: Q_3> Q_x, X и F. Выбор протокола зависит от требований по реализации данной физической конфигурации. Прикладной уровень (верхний уровень семиуров­невой модели взаимодействия открытых систем OSI/ISO) является общим для всех групп протоколов, причем он не всегда требуется. Для интерфейса Q₃ на верхних уровнях (с 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 и управляет, используя интерфейс Q₃ и встроенные каналы управления ЕСС, устройством сопряжения MD и элементами сети NE1 и NE2 через MCF. Кроме этого, через ин­терфейсы Q₃ и Q_x реализуется и стандартная для концепции Менеджер-Агент схема управления уст­ройствами MD, NE1 и управляемым объектом МО.

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

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, например GNE_E - GNEq;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наблюдение за сообщениями об аварийных ситуациях. Оно включает обнаружение таких сооб­щений и фиксацию/сохранение сообщений о тех событиях и условиях, которые сопутствовали их поя­влению, причем не только в том оборудовании, в котором они были обнаружены. 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                                   R¹                Для нагрузки, требующей

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

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

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

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

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

                                                                                  отображения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Таблица 6.2. Стеки протоколов А1 и А2

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

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

На рис. 6.11 приведена модель сети DCN, на которой белые кружочки на концах линий по­казывают положение интерфейсов Q₃, соединительные линии между ними - маршруты связи между выделенными точками, а двухбуквенный код αβ указывает типы сетей, подключенных к интерфейсам и вовлеченных во взаимодействие. Буква α указывает на сеть, с которой данный интерфейс физичес­ки соединен, а буква β - на сеть, с которой соединен другой, взаимодействующий с ним, интерфейс. Например, код интерфейса ga (интерфейс показан у левого верхнего блока CLNS X.25) говорит, что данный интерфейс соединен с сетью CLNS/X.25 (буква g соответствует сети с пакетной коммутаци­ей Х.25, тип сервиса CLNS, см. расшифровку под рисунком) и через сеть DCN по маршруту ga -ag связан с интерфейсом"ag, соединенным с сетью PSPDN (буква a соответствует сети передачи дан­ных общего пользования с пакетной коммутацией PSPON, тип сервиса CONS).

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

Пояснения к рис. 6.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.

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

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

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

Информация в лекции "20 Обзор численных методов решения задачи Коши для обыкновенных дифференциальных уравнений" поможет Вам.

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

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

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

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

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

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