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

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

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

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

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

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

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

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-интерфейс

3.4. Практические методы управления сетью SDH

3.4.1. Сеть управления на основе каналов DCC

3.4.1.1. Спецификация интерфейсов управления

3.4.1.2. Адресация точки доступа сетевого сервиса NSAP

3.4.1.3. Сеть Ethernet

3.4.2. Служебные каналы и внешние интерфейсы

3.4.3. Синхронизация сетей SDH

3.4.3.1. Методы синхронизации

3.4.3.2. Режимы работы и качество хронирующего источника

3.4.3.3. Использование мирового скоординированного времени

3.4.3.4. Пример синхронизации кольцевой сети SDH

3.4.3.5. Пример синхронизации ячеистой сети SDH

3.4.4. Элемент-менеджер

3.4.5. Сетевой менеджер

3.5. Практический пример формирования сети управления для ячеистой сети SDH

3.5.1. Определение адресов NSAP для узлов сети

3.5.2. Формирование сети синхронизации

3.5.3. Соединение и конфигурирование узлов и маршрутизация потоков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для передачи информации между указанными блоками TMN используется функция передачи данных DCF. Пары функциональных блоков, обменивающихся информацией, разделены между собой опорными (или интерфейсными) точками. Три из указанных блоков, выполняющих функции NEF, QAF и WSF, принадлежат TMN лишь частично (рис.3-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, может играть роль либо Менеджера, либо Агента [65,67], используется в функциональных блоках MF, NF, OSF и QSF;

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

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

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

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

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

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

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

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

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

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

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

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

- х - точки между OSF, принадлежащих двум TMN. Точки второй группы делятся на два класса:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Протоколы TMN

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

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

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

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

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

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

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

В свете вышесказанного, рассмотрим более подробно схему управления сетью 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].

3.4. Практические методы управления сетью SDH

3.4.1. Сеть управления на основе каналов DCC

Рассмотрим некоторую обобщенную практическую двухуровневую схему управления сетью SDH, которая состоит, например, из колец SDH, а кольцо состоит из нескольких узлов - мультиплексоров. Соединение колец и узлов формирует SMN. Такое соединение можно сделать, используя либо встроенные каналы связи DCC, которые обеспечиваются самим оборудованием SDH, либо внешнюю кабельную проводку между узлами, реализующую сеть Х.25 или Ethernet. В любом случае каждый узел должен быть доступен для управления. Для защиты наиболее важных участков сети управления может использоваться резервирование.

Маршрутизация в сети управления может осуществляться, например, на основе протокола связи между конечной и промежуточной системами ES-IS [106] или протокола связи между промежуточными системами IS-IS [107], взятых из протоколов, обслуживающих интерфейс Q₃. Это обеспечит автоматическую маршрутизацию как в процессе инсталляции сети, так и при возникновении ошибок в сети, то есть, если какое-то звено сети неисправно, то используется альтернативный маршрут. Схема маршрутизации должна автоматически изменяться и при изменении конфигурации. Обычно используют два-три канала DCC на один узел, чтобы время маршрутизации не было большим, однако при необходимости их число может быть увеличено до семи.

На рис.3-12 приведена практическая схема управления сетью SDH, состоящей из двух колец по четыре мультиплексора в каждом, с элемент-менеджером ЕМ (нижний уровень управления), подключенным к одному из узлов сети (мультиплексору) через интерфейс F, и сетевым менеджером NMS (верхний уровень управления), подключенным через локальную сеть к сети SDH через интерфейс Q₃. Это может быть локальный (для данного кольца) или центральный менеджер. Кольца также соединены между собой по контуру управления через интерфейс Q₃.

3.4.1.1. Спецификация интерфейсов управления

С учетом вышесказанного приведем сводные данные по локальной сети и интерфейсам управления Q₃ и F. Для конкретного примера выберем LAN Ethernet типа 10BASE2, которой соответствует набор протоколов CLNS1. Тогда профили стеков протоколов SDH и Q₃ и протоколы маршрутизации, используемые в управлении сети SDH, регламентируются стандартами и рекомендациями, приведенными в таб.3-3.

Элемент-менеджер формально соединен с сетью через интерфейс F, фактически же при использовании локальной сети Ethernet это тот же интерфейс Q₃ с указанными протоколами уровня 2. Учитывая, что применена сеть Ethernet 10BASE2 с тонким коаксиальным кабелем, используются соединительные разъемы типа ВNС с импедансом 50 Ом.

3.4.1.2. Адресация точки доступа сетевого сервиса NSAP

Каждый узел сети управления должен иметь свой адрес точки доступа сетевого сервиса NSAP. Этот адрес присваивается узлу при инсталляции. Он уникален и служит для идентификации узла при его подключении к ЕМ или NMS.

При управлении конкретной сетью важным параметром является максимальное число узлов (мультиплексоров), управление которыми возможно. Допустим, что это число равно 100. Тогда, если число узлов в результате роста сети превысило этот показатель, то сеть управления должна быть разбита на области с меньшим числом управляемых узлов. Если такое разбиение необходимо, то оно должно быть проведено с учетом целого ряда ограничений обычно указываемых в руководствах по маршрутизации.

Некоторые вещи полезно знать для того, чтобы осуществить такое разбиение:

-         наиболее удобной топологией для сети управления, имеющей несколько областей, является топология "звезда" (например, область в виде квадрата, можно разбить делением сторон пополам, что дает 4 симметричные области с центром в центре квадрата),

-         области управления могут не иметь ничего общего с топологией транспортной сети SDH (хотя это и рекомендуется),

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

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

Структура адреса NSAP показана рис.3-13. Максимальная длина его - 20 байтов.

Адрес NSAP состоит из двух частей адреса домена: начальной и специфической - IDР и DSP. Начальная часть домена IDР в свою очередь состоит из двух полей: поля идентификатора полномочий и формата AFI (длиной в 1 байт) и начального идентификатора домена IDI (длиной в 2 байта). Они фиксируются локальной схемой нумерации, которой они и следуют. Так как нет жестко регламентирующих правил нумерации адреса, то лучше придерживаться схемы нумерации, данной в стандарте ISO 10589 [107] для данного протокола. Структура специфической части домена DSP соответствует протоколу IS-IS, выбранному в нешем примере в качестве протокола маршрутизации. Пример генерации и использования адреса NSAP приведен в п. 3.5.

Внутри одной области начальная часть домена IDР и адрес области АА (длиной в 10 байтов) постоянны. Только идентификатор системы SID (длиной в 6 байтов) изменяется от узла к узлу в одной области, но его размер остается постоянным. Поле NSEL имеет длину в один байт и принимается постоянным и равным 0.

3.4.1.3. Сеть Ethernet

Если в качестве локальной сети используется сеть Ethernet, то узлы в одной станции могут быть соединены с помощью кабелей Ethernet. Максимальное число узлов сети Ethernet, которое может иметь одна станция (один или несколько узлов, имеющих одно функциональное назначение) сети SMN, ограничено. Это число может быть, например, 15, что ограничивает общее число узлов сети SMN, подключенных к сети Ethernet. Образующиеся отдельные "островки" сети Ethernet могут быть соединены мостами, причем каждое такое соединение защитывается как один дополнительный узел сети Ethernet.

Все подключения кабелей к панели разъемов мультиплексоров SDH (полок в пределах одной стойки), при объединении нескольких узлов SMN кабелями Ethernet, должны быть сделаны до инициализации сети Ethernet так, как показано на рис.3-14. Если такими же кабелями соединяются стойки, то должен соблюдаться тот же принцип соединения. При наличии разного числа (1 или 2) блоков управления CU на полках необходимо следовать указаниям руководства по установке полок в стойку конкретного производителя оборудования.

3.4.2. Служебные каналы и внешние интерфейсы

Как уже упоминалось выше (2.2.9), заголовки SОН и РОН фрейма STM-N имеют достаточно большую резервную емкость, которая может быть использована для формирования различных служебных каналов. Общий объем заголовка составляет 90 (81+9) байт. Использование каждого байта эквивалентно

созданию 64 кбит/с канала. Все указанные байты могут быть разделены на три типа (рис.3-15):

-    байты, которые не могут эксплуатироваться пользователями SDH оборудования (их 36, они заштрихованы на рис.3-15),

-    байты, которые специально предназначены для использования в служебных целях или для создания служебных каналов (их 16, они помечены символом и номером, например, Е1); к ним относятся, например, канал DCC_R (D1,D2,D3), имеющий скорость 192 кбит/с для обслуживания регенераторных секций, канал DCC_M (D4-D12) - 576 кбит/с для обслуживания мультиплексных секций; кроме этого существуют еще 4 байта - Е1, Е2 и F1, F2, зарезервированые для создания четырех каналов 64 кбит/с,

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

Последние две группы байтов могут быть сгруппированы для создания служебных каналов и скоммутированы на внешние интерфейсы, к которым может подключаться пользователь SDH оборудования. Число таких интерфейсов (а значит и вариантов группирования) зависит от производителя оборудования. Например, компания Nokia в мультиплексорах уровня STM-1, 4 обеспечивает 4/6 таких интерфейса (рис.3-16).

Как видно из рис.3-16 и описано в [115], блок внешних интерфейсов позволяет осуществить ряд вариантов группирования каналов, а также следующие функции:

-    подключение физических интерфейсов (например, V.11 или G.703) к выбранным байтам заголовка фрейма STM-N;

-    две специальные функции с гибридным набором данных DH 1, DH 2 для данных, взятых из избранных байтов заголовка фрейма ОН или из физического интерфейса V.11;

-    подключение стека Q₃ к выбранным байтам заголовка фрейма ОН или к внешнему физическому интерфейсу (AUX-3).

Такая организация внешних интерфейсов и наличие гибридных наборов данных позволяет с помощью сети SDH осуществлять управление PDH оборудованием, подключенным к мультиплексорам SDH с помощью интерфейсов V.11, используя каналы управления 64 кбит/с, сформированные пользователем на основе байтов заголовка фрейма ОН. Это дает возможность создавать на базе единой сети управления гибридные PDH-SDH комплексы, продляя жизнь оборудованию PDH.

Использование стека Q₃ вместе с каналами данных через AUX-3 позволяет осуществить маршрутизацию управляющей информации через сеть, которая не может напрямую использовать каналы ЕСС.

3.4.3. Синхронизация сетей SDH

Проблема синхронизации сетей SDH является частью общей проблемы синхронизации цифровых сетей, использующих ранее плезиохронную иерархию. Общие вопросы синхронизации, описанные в рекомендации CCITT G.810 [116], актуальны как для плезиохронных, так и для синхронных сетей. Отсутствие хорошей синхронизации приводит, например, к относительному "проскальзыванию" цифровых последовательностей или "слипам" (slip) и ведет к увеличению уровня ошибок синхронных сетей.

Цель синхронизации - получить наилучший возможный хронирующий источник или генератор тактовых импульсов или таймер для всех узлов сети. Для этого нужно не только иметь высокоточный хронирующий источник, но и надежную систему передачи сигнала синхронизации на все узлы сети.

Система такого распределения базируется в настоящее время на иерархической схеме, заключающейся в создании ряда точек, где находится первичный эталонный генератор тактовых импульсов PRC (ПЭГ), или первичный таймер, сигналы которого затем распределяются по сети, создавая вторичные источники - вторичный или ведомый эталонный генератор тактовых импульсов SRC (ВЭГ), или вторичный таймер, реализуемый либо в виде таймера транзитного узла TNC, либо таймера локального (местного) узла LNC. Первичный таймер обычно представляет собой хронирующий атомный источник тактовых импульсов (цезиевые или рубидиевые часы) с точностью не хуже 10^-11. Он обычно калибруется вручную или автоматически по сигналам мирового скоординированного времени UTC [117]. Эти сигналы затем распространяются по наземным линиям связи для реализации того или иного метода синхронизации.

3.4.3.1. Методы синхронизации

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

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

Как было указано в п.2.7.2, а также рассмотрено в [29], сети SDH имеют несколько дублирующих источников синхронизации:

-    сигнал внешнего сетевого таймера, или первичный эталонный таймер PRC, определяемый в рекомендации ITU-T G.811 [118], сигнал с частотой 2048 кГц (см. ITU-T G.703, п. 10 [14]);

-    сигнал с трибного интерфейса канала доступа (рассматриваемый здесь как аналог таймера транзитного узла TNC), определяемый в рекомендации ITU-T G.812 [119], сигнал с частотой 2048 кГц, выделяемый из первичного потока 2048 кбит/с;

-    сигнал внутреннего таймера (рассматриваемый как таймер ведомого локального узла LNC), определяемый в рекомендации ITU-T G.813 [163], сигнал 2048 кГц;

-    линейный сигнал STM-N, или линейный таймер, сигнал 2048 кГц, выделяемый из линейного сигнала .155.520 Мбит/с или 4n x 155.520 Мбит/с.

Учитывая, что трибы 2 Мбит/с, пришедшие из сетей SDH, отображаются в VC-12 и могут плавать в рамках структуры вложенных контейнеров, использующих указатели, их сигналы должны быть исключены из схемы синхронизации сети SDH. Реализуемая точность внутреннего таймера, равная 5x10^-6 - мала, учитывая возможность накапливания ошибки в процессе так называемого "каскадирования сигналов таймеров", когда узел сети восстанавливает сигнал таймера по принятому сигналу и передает его следующему узлу. В этом смысле наиболее надежными источниками синхронизации являются сигнал внешнего сетевого таймера и линейный сигнал STM-N.

Целостность синхронизации сети PDH базировалась на использовании иерархической принудительной синхронизации (ведомый/ведущий таймеры). В ней прохождение сигналов таймеров через узлы сети было прозрачным. В сети SDH, восстанавливающей в каждом узле сигнал таймера из линейного сигнала STM-N, такая прозрачность теряется. В этой ситуации целостность синхронизации сети SDH лучше поддерживается при использовании распределенных первичных эталонных источников PRS, что позволяет устранить эффекты "каскадирования сигналов таймеров" [117]. Метод распределенных PRS описан в стандарте Bellcore GR-2830-CORE [120].

3.4.3.2. Режимы работы и качество хронирующего источника

Предусматривается четыре стандартных режима работы хронирующих источников узлов синхронизации:

а) режим первичного эталонного таймера PRC или генератора ПЭГ (мастер узел);

б) режим принудительной синхронизации - режим ведомого задающего таймера SRC или генератора ВЗГ (транзитный и/или местный узлы);

в) режим удержания с точностью удержания 5x10^-10 для транзитного узла и 1x10^-8 для местного узла и суточным дрейфом 1x10^-9 и 2x10^-8 соответственно [160].

г)  свободный режим (для транзитного и местного узлов) - точность поддержания зависит от класса источника и может составлять 1х10^-8 для транзитного и 1х10^-6 для местного узлов [160].

Организации ITU-T и ETSI предложили использовать понятие уровень качества хронирующего источника. Этот уровень может быть передан в виде сообщения о статусе синхронизации SSM  через  заголовок  фрейма  STM-N  для  чего  используются   биты   5-8  байта  синхронизации (например, S1), или последовательностью резервных бит в фрейме Е1 2 Мбит/с. В этом случае при сбое в сети, повлекшем защитное переключение, сетевой элемент имеет возможность послать сообщение таймеру о необходимости использовать сигнал синхронизации, восстановленный из альтернативного маршрута.

Современные системы управления сетью могут использовать до шести уровней качества хронирующего источника (таблицу 3-4).

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

3.4.3.3. Использование мирового скоординированного времени

Среди хронирующих источников наиболее универсальным и точным является мировое скоординированное время UTC. Для его трансляции используются спутниковые системы LORAN-C и глобальная система позиционирования GPS. Традиционные системы приема UTC требуют значительных затрат и используются как правило в центрах спутниковой связи. Однако в связи с широким развитием GPS была разработана альтернатива первичным эталонным источникам PRS - технология локальных первичных эталонов LPR, основанная на использовании UTC для подстройки частоты. Многиетелефонные компании используют эту технологию в местах развертывания GPS для создания альтернативы таймерам класса TNC на транзитных узлах. На таких узлах в качестве таймеров TNC устанавливаются улучшенные рубидиевые часы. В комбинации с технологией LPR использование синхронизации от UTC позволяет получать локальные первичные эталоны существенно перекрывающие требования по точности 10'¹¹, устанавливаемые стандартами ITU-T и ETSI для первичных эталонных таймеров.

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

3.4.3.4. Пример синхронизации кольцевой сети SDH

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

При аккуратном формировании сетевой синхронизации можно избежать возникновения замкнутых петель синхронизации как в кольцевых, так и в ячеистых сетях. Использование сообщений о статусе синхронизации позволяет в свою очередь повысить надежность функционирования сетей синхронизации. На рис.3-17 приведена схема синхронизации кольцевой сети SDH, где верхняя схема соответствует нормальному функционированию сети, а нижняя - сбою, вызванному разрывом кабеля между узлами В и С. [115].

Схема использует ставший классическим иерархический метод принудительной синхронизации. Один из узлов (узел А) назначается ведущим (или мастер-узлом) и на него подается сигнал синхронизации от внешнего PRC. От этого узла основная синхронизация (источник первого приоритета) распределяется в направлении против часовой стрелки, т.е. к узлам В, С и D. Синхронизация по резервной ветви (источник второго приоритета) распределяется по часовой стрелке, т.е. к узлам D, С и В. Начальное распределение хронирующих источников по узлам сведено в таблицу 3-4.

При разрыве кабеля между узлами В и С узел С, не получая сигнала синхронизации от узла В, переходит в режим удержания синхронизации и посылает узлу D сообщение о статусе SETS уровня качества синхронизации. Узел D, получив сообщения об уровне качества синхронизации от А и С и выбрав лучший (от А), посылает узлу С сообщение "PRC" вместо "Don't use". Узел С, получив это сообщение от узла D, изменяет источник синхронизации на "PRC" от D.

3.4.3.5. Пример синхронизации ячеистой сети SDH

Рассмотрим схему синхронизации в ячеистой сети SDH. Один из примеров формирования цепей синхронизации в такой сети приведен на рис.3-18 [115]. Сеть имеет 12 узлов и несложную транспортную топологию звезды, включающую несколько линейных участков, связанных через узлы концентраторов.

Для облегчения задачи построения сети синхронизации схема разбивается на несколько цепей синхронизации, учитывая при этом особенности топологии исходной транспортной сети. Полученные цепи: W, X, Y, Z - показаны в нижней части рис.З-18. Цифрами 1 и 2 на этом рисунке показаны приоритеты в использовании сигналов синхронизации. Сплошной линией показаны основные каналы синхронизации, пунктиром - резервные каналы синхронизации. Мастер-узлы заштрихованы.

Для распределения синхронизации используется та же иерархическая схема. Каждая цепь синхронизации может быть обеспечена одним или двумя узлами, получающими синхронизацию от внешних источников (PRC). Эти узлы называют мастер-узлами. Источник PRC, расположенный на основной станции, является внешним PRC, от которого получают синхронизацию два мастер-узла W и X цепей W и X. Цепи Y и Z имеют общий мастер-узел C&D, который получает сигнал синхронизации от последнего узла цепи X. Суть предложенного решения состоит в организации альтернативного пути передачи сигнала синхронизации в каждой цепи. Проблемы могут возникнуть только при низкой надежности связи, обеспечивающей синхронизацию мастер-узлу C&D. В этом смысле для этого мастер-узла логично использовать локальный первичный эталон LPR.

3.4.4. Элемент-менеджер

Элемент-менеджер ЕМ - это прикладной программный продукт, разрабатываемый производителями оборудования SDH для управления и мониторинга отдельных элементов сети SDH. Его также называют узловым менеджером NM, так как фактически он управляет узлом сети SDH, который может содержать несколько элементов SDH. Элемент-менеджер может быть использован для управления не только локальными, но и удаленными узлами сети. Он может быть также использован в полевых условиях для ремонтных работ и инсталляции новых узлов, а также для контроля за функционированием узлов.

Элемент-менеджеры могут быть реализованы на различных компьютерных платформах в том числе и на IBM PC совместимых компьютерах под управлением различных операционных систем, например, Windows, Windows 95, Windows NT. Информация, получаемая в процессе работы элемент-менеджера, может храниться в файле или в базе данных, используемой менеджером сети SDH. Основное окно ЕМ, кроме стандартных для оконных интерфейсов опций - Options, Window, Help, содержит по крайней мере следующие опции: Node - для работы с узлом или элементом сети, Data - для отображения хранящейся информации, Monitor - для мониторинга сообщений о возникновении аварийных ситуаций и рабочих характеристик оборудования и Configure - для инсталляции новых узлов и изменения конфигурации узлов.

На рис.3-19 показан, на примере NM компании Nokia [121], вид основного окна приложений ЕМ, на котором отображены два других окна:

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

- окно текущих сообщений о возникновении аварийных ситуаций, где отображается степень их серьезности, их тип и другие детали.

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

Управление синхронизацией

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

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

- устанавливаются приоритеты в выборе эталонных источников;

- устанавливаются уровни качества передаваемых сигналов 2 Мбит/с и соответствующих им сигналов синхронизации частотой 2 МГц;

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

- выбирается сигнал таймера, который посылается с внешнего интерфейса.

Так как сигналы 2 Мбит/с и входные сигналы синхронизации 2 МГц не несут сообщений SSM, оператор может установить им желаемый уровень качества (с помощью ЕМ) вплоть до PRC, если входной сигнал 2 МГц был взят от источника высокого класса.

ЕМ может использовать три режима работы системы синхронизации:

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

-    режим ручного выбора источника синхронизации;

-    режим удержания синхронизации.

Образец экрана ЕМ, отображающего режим синхронизации, показан на рис.3-20 [121].

На экране показан режим использования списка приоритетов и видны два окна: одно со списком приоритетов источников, другое со списком возможных источников, где указаны имена источников, уровни их качества и доступность в данный момент. На экране также есть панели режимов и статуса источника.

Конфигурирование кросс-соединений

Мультиплексоры ввода/вывода и блоки кросс-коммутации способны осуществлять кросс-соединения на уровне различных виртуальных контейнеров в зависимости от типа оборудования SDH и его производителя. Однако, если кросс-соединение на уровне VC-3 и VC-2 (триб 6 Мбит/с) делают только некоторые производители, а для VC-2, как правило, по запросу пользователя, то на уровне VC-4 и VC-12 (для европейских потребителей) кросс-соединение реализовано практически на любом типе такого оборудования. Режим такого соединения - двунаправленный.

Конфигурирование кросс-соединений может быть осуществлено элемент-менеджером по специальной таблице кросс-соединений, формируемой в процессе конфигурирования узла.

Мониторинг аварийных сообщений и рабочих характеристик

Сообщения об аварийных ситуациях могут отображаться как аппаратными средствами (например, светодиодными индикаторами (LED)), так и программным путем на экране дисплея ЕМ. При этом на экране может отображаться:

-    источник аврийного сообщения,

-    степень серьезности или статус проблемы (путем использования различных цветов у индикатора),

-    список аварийных сообщений, относящихся к данному узлу,

-    список аварийных сообщений, относящихся к данному блоку,

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

Цвет индикатора аварийного сообщения или сообщения о возникновении аварийного сообщения может быть различный, например: красный, желтый и белый - в зависимости от степени серьезности проблемы, отражаемой индикатором или сообщением: красный - наиболее серьезная проблема, требующая активных действий, например, резервного переключения, желтый - предупреждение о возможном критическом значении параметра, белый - все в порядке. Иногда аварийные сообщения разбиваются на две группы А-сообщения и В-сообщения, где А-сообщения эквивалентны критическим или главным, а В-сообщения - второстепенным по степени серьезности последствий. Кроме А- и В-сообщений могут использоваться и D-сообщения, сигнализирующие об отключении А- и В-сообщений определенной группы.

Что касается мониторинга рабочих характеристик блоков, то режим мониторинга (например, 15 минутные или 24 часовые интервалы) может быть установлен с помощью ЕМ. Соответствующие результаты мониторинга сохраняются так, как было описано выше. В таблице 3-5 показаны типы ошибок, фиксируемых при мониторинге - ES, SES, BE, UAS, и типы функциональных блоков, для которых они вычисляются - RST, MST, HPT, LPT, EPPI.

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

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

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

BE                  - блок с ошибками,

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

RST                - окончание регенераторной секции,

MST                - окончание мультиплексной секции,

НРТ                - окончание маршрута контейнеров VC верхнего уровня,

LPT                 - окончание маршрута контейнеров VC нижнего уровня,

EPPI 2M        - физический интерфейс PDH 2 Мбит/с,

EPPI 140M    - физический интерфейс PDH 140 Мбит/с,

BSMM            - bsmm           - байт-синхронный режим отображения,

АММ               - amm             - асинхронный режим отображения.

3.4.5. Сетевой менеджер

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

-         мониторинг - проверка маршрута (тракта) передачи,

-         управление сетевой топологией,

-         осуществление сетевого сервиса и обработка информации от сетевых элементов NE.

Функции управления, осуществляемые NM, как правило, соответствуют ряду рекомендаций и стандартов, среди которых ITU-T G.784 [23], М.ЗОЮ [60], Х.217 [99], Х.227 [100], Х.219 [101], Х.229 [102], ISO 9595 [103], ISO 9596 [83]. Как и ЕМ, но в более широких масштабах, NM осуществляет:

- обработку аварийных сообщений,

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

- управление конфигурацией,

- управление программой обслуживания сети и тестирования ее элементов,

- управление безопасностью системы,

- административное управление.

NM реализуется как правило на достаточно мощных рабочих станциях, работающих под OS Unix, таких как станции SUN SPARC (OS Solaris) или Hewlett Packard (OS OpenView). Используемое программное обеспечение, как правило, разрабатывается самой фирмой, хотя в последнее время наметилась тенденция использования сетевого менеджера "OpenView" компании Hewlett Packard, как наиболее совершенного, в качестве основы для создания NM.

Если рассмотреть в качестве образца сетевой менеджер ENM компании ECI [122], то он реализован на базе рабочей станции SUN SPARC по управлением OS Solaris (Unix-подобная OS) и имеет шесть основных опций - Alarm, Performance, Configuration, Maintenance, Security, System, в точности соответствующих шести вышеперечисленным задачам управления. Каждая опция позволяет генерировать свои экраны в соответствии с элементами меню опции, отображающими выполняемую функцию или задачу. На рис.3-21 представлен основной экран NM с открытыми экранами обработки потока аварийных сообщений и управления рабочими характеристиками.

Обработка аварийных сообщений.  Эта опция позволяет:

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

-         просматривать текущие аварийные сообщения в соответствии с выбранным критерием;

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

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

Управление рабочими характеристиками. Эта опция дает оператору или менеджеру сети возможность:

-         открыть и просмотреть окно с итоговыми данными по рабочим характеристикам для конкретного объекта;

-         просмотреть динамику изменения рабочих характеристик конкретного объекта;

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

-         сбросить счетчики, используемые при определении (вычислении) рабочих характеристик.

На рис.3-21 справа показано окно, отображающее текущие рабочие характеристики мультиплексора уровня STM-4 - всего 9 параметров.

Управление конфигурацией.   Эта опция позволяет:

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

-         присваивать и модифицировать атрибуты объектов;

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

-         выбирать возможный источник синхронизации в качестве эталонного;

-         конфигурировать сетевые элементы и сетевую топологию.

Управление программой обслуживания сети и тестирования ее элементов. Эта опция позволяет:

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

-         осуществлять диагностику выбранного объекта;

-         осуществлять перезагрузку системы управления;

-         искусственно инициировать поток аварийных сообщений для выбранного объекта;

-         искусственно инициировать поток сигналов сбоя для выбранного объекта;

-         блокировать автоматическое защитное переключение активного кольца;

-         вручную переключать активное кольцо на резервное.

Управление безопасностью системы. Эта опция позволяет:

-         устанавливать и менять пароли;

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

-         создавать списки групп пользователей с определенным уровнем доступа;

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

Административное управление. Эта опция позволяет:

-         распечатывать отчеты и сообщения, как стандартные для системы, так и сформированные оператором или администратором;

-         осуществлять резервное копирование баз данных;

-         загружать базы данных информацией из файлов пользователя;

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

-         осуществлять процедуры регистрации пользователей системы NM.

3.5. Практический пример формирования сети управления для ячеистой сети SDH

Рассмотрим пример формирования сети управления для ячеистой сети SDH.

В соответствии с вышесказанным в разделе 3.4.1. в качестве основных каналов управления сетью

SDH используются каналы DCC. Для этих же целей могут быть использованы и каналы сети Ethernet.

Если сеть достаточно большая и разбита на несколько областей, то должны быть определены связи между ними, адреса NSAP отдельных узлов и маршруты для передачи информации управления.

В качестве примера ячеистой сети SDH, рассмотрим сеть, уже описанную в разделе 2.7.3. Для нее одним из вариантов формирования сети управления может быть сеть, показанная на рис.3-22 [115]. На нем показаны фактически две сети - одна использует каналы DCC, объединяет все шесть узлов (A-F) ячеистой сети, другая - использует каналы Ethernet, объединяет три станции узла А (А1-АЗ). К последней из них - A3, присоединен узловой менеджер на базе PC.

3.5.1. Определение адресов NSAP для узлов сети

Структура адреса NSAP была приведена на рис.3-13. Единственным уточнением может быть то, что поле "адрес области" (10 байт) может быть разбито на две части: адрес домена (Domain - 8 байтов) и собственно адрес области (Area - 2 байта).

На практике адреса NSAP должны контролироваться (распределяться) некой сетевой администрацией страны, где развертывается такая сеть, и схема нумерации должна быть локальной для данной страны. Если сама сеть управления локальна и не соединяется ни с какой другой сетью управления, то схема нумерации (отражаемая полем IDI) может быть выбрана достаточно произвольно. Код страны в сетях передачи также должен регламентироваться определенным стандартом. Им является стандарт ISO 3166, который содержит список трехзначных десятичных (двухзначных шестнадцатиричных) кодов, выделенных для каждой страны и используемых для заполнения поля AFI.

В этой связи в данном примере используется произвольный адрес страны IDI = 001F, а также произвольный идентификатор AFI = 39. Адрес собственно области - 1, адрес домена - 1, то есть поле адреса области АА = 00000000000000010001. Поле NSEL=0. Эти адресные поля остаются постоянными для всех узлов рассматриваемой в данном примере сети SDH.

Системный идентификатор SID должен быть уникальным в данной области и должен отражать структуру используемой сети SDH. В данном примере используется следующая структура SID: поле с номером станции (Station - 3 байта), поле с номером отсека (места установки), где установлено оборудование (Room - 1 байт), и поле с номером полки (Subrack - 2 байта). С учетом этого в таб.3-6 помещены значения системных идентификаторов (исключая первые два нулевых байта - 0000) для различных узлов сети. Именно эти идентификаторы приведены на рис.3-22.

Таблица 3-6. Значения системных идентификаторов для узлов сети

3.5.2. Формирование сети синхронизации

Рассмотрим формирование сети синхронизации для той же ячеистой сети. Для этого используем общие подходы рассмотренные ранее. Разбиваем сеть на три секции с логически связанными узлами, (рис.3-23). Первая секция состоит из четырех узлов: А, С, D, В; вторая - из двух: Е и F ; третья - фактически содержит один узел А, т.е. А, А1, А2, A3.

В результате получаем общую схему синхронизации, показанную на рис.3-24. Схема содержит один первичный источник PRC (Узел А) и один вторичный источник в транзитном узле (G.812T - Узел В). Сплошными линиями показаны цепи первичной синхронизации, а штриховыми линиями - цепи вторичной синхронизации.

Списки источников синхронизации, выбираемых по номеру приоритета для каждого узла, сведены в таблицу 3-7. Каждый узел, кроме узлов А1, А2, A3, имеет по три источника синхронизации с номерами, соответствующими порядку приоритета (т.е. 1, 2, 3). Номера слотов, откуда поступают сигналы синхронизации, соответствуют схеме установки сменных блоков оборудования в слотах, приведенной на рис.2-48.

3.5.3. Соединение и конфигурирование узлов и маршрутизация потоков

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

Примерная процедура инициализации узла включает следующие этапы:

-         подключить интерфейс F очередного узла (например А) к NM и запустить NM,

-         ввести данные о типе узла, типе полки, имени узла и имени станции, где он расположен,

-         установить требуемое программное обеспечение блоков узла,

-         ввести адрес NSAP,

-         перезагрузить систему и войти по введенному адресу NSAP,

-         отредактировать приоритеты в списке источников синхронизации,

-         сконфигурировать каналы управления DCC,

-         сконфигурировать используемые блоки STM-N, снабдить каждый законченный временный маршрут контейнера VC-4 идентификатором трассировки временного маршрута TTI.

Длина TTI не должна превышать 15 символов, если придерживаться при его формировании правил, предложенных ETSI и основанных на рекомендации ITU-T Rec. E.164 [139]. Он должен содержать как минимум имена исходного узла и узла назначения, символьный код виртуального контейнера (например, А, В, С и D соответствуют VC-12, VC-2, VC-3 и VC-4), номер тайм-слота терминального кросс-коммутатора, осуществляющего вывод заданного виртуального контейнера. Описать это более подробно можно только на примере конкретного оборудования. Идентификаторы TTI позволяют контролировать корректность установки таблицы кросс-коммутации у кросс-коммутаторов на всем пути следования виртуального контейнера.

Параллельно формируется таблица маршрутизации виртуальных контейнеров с указанием того, какие интерфейсы на оконечных узлах должны быть задействованы. Конкретный пример маршрутизации потока 2 Мбит/с между узлами А и С сети, рассмотренной в разделах 2.7.3. и 3.4. приведен в таб. 3-8 [58].

Пример физической связи узлов А (соединительный разъем Т4А, интерфейс 7) и С (соединительный разъем Т4А, интерфейс 5) по каналу 2 Мбит/с показан на рис.3-25. Сигнал этого канала передается в структуре сигнала STM-4 в канале 1,3,1 (в кодировке Nokia) первого виртуального контейнера VC-4. Имя, используемое для кросс-коммутации может быть одним и тем же для всего временного маршрута.

Рассмотренные в этой главе задачи, методы и практические схемы управления сетями SDH выявили ряд характерных моментов. Наиболее важным из них является существование общих черт в управлении сетями передачи данных, использующих различные технологии. Это делает оправданным рассмотрение общей модели управления сетью и общей схемы управления сетью. С этой точки зрения задача управления сетью SDH может рассматриваться как частный случай общей задачи управления. Наиболее важным вкладом здесь является применимость к этой частной задаче управления рассмотренных протоколов, логики внутрисистемных взаимодействий и концепции Менеджер-Агент, а также возможность использования общих интерфейсов Q и F для связи отдельных подсистем в единую схему управления сетью SDH.

Приходится, однако, констатировать, что до сих пор нет единой системы управления сетями SDH, которая, как, например, сетевая ОС Novell Netware для локальных сетей, могла бы после стандартной процедуры настройки управлять сетями SDH, использующими оборудование различных производителей. Более того, даже сам факт построения общей сети SDH, составленной из мультиплексеров различных производителей, хотя бы даже и одного уровня STM-N, пока невозможен.

Большим позитивным сдвигом в сторону решения этой проблемы несомненно явилась осуществляемая детальная проработка стандартов Q-интерфейса и их внедрение в разработку общих схем управления оборудованием SDH. Однако и в этом плане пока нельзя сказать, что все вопросы практического управления сетью SDH решены. В этой связи ценным, по мнению автора, может оказаться рассмотрение ряда практических вопросов управления ячеистой сетью и решение вопросов ее синхронизации на примере конкретной сети.

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