3.1. Четырехуровневая модель управления сетью
3.2. Сеть управления телекоммуникациями TMN
3.2.1. Концепция TMN и общая схема управления
3.2.2.1. Функциональные блоки и их компоненты
3.3. Общая схема управления сетью SDH
3.3.1. Подсеть SMS сети управления SMN
3.3.2.1. Общие функции управления
3.3.2.2. Управление сообщениями об аварийных ситуациях
3.3.3. Протоколы и внутрисистемные взаимодействия
3.3.4. Интерфейсы взаимодействия
3.4. Практические методы управления сетью SDH
3.4.1. Сеть управления на основе каналов DCC
3.4.1.1. Спецификация интерфейсов управления
3.4.2. Служебные каналы и внешние интерфейсы
3.4.3. Синхронизация сетей SDH
3.4.3.2. Режимы работы и качество хронирующего источника
3.4.3.3. Использование мирового скоординированного времени
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, т.е. оборудованием (мультиплексорами, коммутаторами, регенераторами и т.д.) сети. Его задачи:
— конфигурация элементов сети — установление параметров конфигурации, например, назначение каналов, распределение трибных интерфейсов, установка реального времени;
— мониторинг — определение степени работоспособности (статуса), сбор и обработка сигналов о возникновении аварийных ситуации (алармов — А), несущих информацию типа «в элементе сети NEi произошла ошибка Ai«;
— управление функцией передачи — управление операционными параметрами, отвечающими за функционирование сети, а именно: проверка состояния интерфейсов, активация систем защиты для переключения на резервное оборудование;
— управление функциями TMN — управление потоками сигналов о возникновении аварийных состояний, адресация возникающих при этом сообщений, формирование критериев фильтрации ошибок, маршрутизация пакетов сообщений по служебным каналам, формируемым за счет SОН в фреймах SDH, генерация и мониторинг сигналов синхронизации;
— тестирование элементов сети — проведение тестов, характерных для данного типа оборудования;
— локализация NE в рамках выделенного слоя — осуществление сервиса NE и обработка информации от NE, специфических для данного слоя.
Функции ЕМ могут интерпретироваться как независимые функции OS, осуществляемые конкретными NE c помощью данного ЕМ через сервисные интерфейсы, поддерживаемые данной OS. Для осуществления этих функций все NE должны быть известны и различаемы для конкретной OS. Если несколько OS реализуют одни и те же сервисные интерфейсы, то в этом случае функции элемент-менеджмента могут быть распределены по нескольким OSi, как это показано ниже на рис.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]. Здесь OSi могут быть связаны между собой через общую сеть передачи данных 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]; эти точки — делятся на два типа:
— qx — точки между двумя блоками MF или блоком MF и остальными блоками;
— q3 — точки между двумя блоками 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, Q3. Взаимодействие осуществляется через сеть передачи данных DCN, реализующую протоколы уровней OSI 1-3 и поддерживающую функцию DCF. DCN может состоять из нескольких связанных между собой подсетей различного типа. Например, это могут быть подсети, образованные каналами связи данных типа DCC в сетях SDH.
Через интерфейс F сеть DCN связана с рабочей станцией WS, играющей роль монитора управляющей системы. Интерфейс X связывает DCN с «внешним миром», через интерфейс Q3 DCN может быть напрямую связана с сетевым элементом NE или с Q-адаптером QA, позволяющим подключать оборудование, имеющее несовместимые с TMN интерфейсы. Наконец, через интерфейсы 03 и F сеть DCN подключается к устройствам сопряжения MD.
Устройства MD, в свою очередь, через интерфейс Qх подключаются к другим DCN или к подсетям той же DCN, которые через интерфейсы Qx связаны напрямую с NE и QA.
Протоколы TMN
Кроме указанных выше протоколов CMIP, CMIS, существуют группы протоколов, поддерживающих каждый из указанных выше интерфейсов: Q3, Qx, X и F. Выбор протокола зависит от требований по реализации данной физической конфигурации. Прикладной уровень (верхний уровень семиуровневой модели взаимодействия открытых систем OSI/ISO) является общим для всех групп протоколов, причем он не всегда требуется. Для интерфейса Q3 на верхних уровнях (с 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 и управляет, используя интерфейс Q3 и встроенные каналы управления ЕСС, устройством сопряжения MD и элементами сети NE1 и NE2 через MCF. Кроме этого, через интерфейсы Q3 и Qx реализуется и стандартная для концепции Менеджер-Агент схема управления устройствами MD, NE1 и управляемым объектом МО.
Во втором примере используется только эта стандартная схема управления всеми устройствами, поддержанная функцией MF-MAF и осуществляемая через интерфейсы Q3 и Qx.
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, например GNEE – CNEG;
— функция MCF имеет возможность завершать, маршрутизировать или обрабатывать сообщения, передаваемые по ЕСС или через внешний Q-интерфейс;
— на основе ЕСС можно сформировать звено связи между офисами или местами установки оборудования;
— в пределах одного места установки оборудования можно организовать связь, используя либо встроенные каналы управления ЕСС, либо локальную сеть связи LCN.
Топология SMS и ЕСС
Каждая SMS должна иметь хотя бы один элемент, соединенный с MD или OS, он называется шлюзовым элементом сети GNE, так как служит шлюзом в подсеть SMS.
На топологию сети ЕСС не накладывается ограничений — это может быть звезда, шина, кольцо или ячеистая сеть.
3.3.2. Функции Управления
3.3.2.1. Общие функции управления
Управление каналами ЕСС. Так как ЕСС используются для связи NE, то каналы ЕСС должны иметь следующие функции:
— запрос/получение сетевых параметров, таких как размер пакета, временные промежутки, качество сервиса и т.д.;
— формирование маршрутизации сообщения между узлами DCC;
— менеджмент сетевых адресов (возможное преобразование форматов адресов);
— запрос/получение сетевого статуса DCC для данного узла;
— возможность разрешать/запрещать доступ к DCC.
Фиксация временных событий. На все события, требующие фиксации во времени ставится временная метка с разрешением в одну секунду. Время фиксируется по показанию локального таймера NE.
Другие функции. Другие общие функции, например, защита на различных уровнях или обеспечение безопасности, дистанционный вход в сеть, загрузка и модификация программного обеспечения, обеспечиваются в настоящее время производителями SDH оборудования.
3.3.2.2. Управление сообщениями об аварийных ситуациях
Наблюдение за сообщениями об аварийных ситуациях. Оно включает обнаружение таких сообщений и/фиксацию/сохранение сообщений о тех событиях и условиях, которые сопутствовали их появлению, причем не только в том оборудовании, в котором они были обнаружены. OS SMN должна поддерживать следующие функции:
— автономное сообщение о всех сигналах о возникновении аварийной ситуации;
— запрос на обобщение о всех зарегистрированных сигналах о возникновении аварийной ситуации;
— сообщение о всех таких сигналах;
— разрешение/запрет на автономное сообщение о всех сигналах о возникновении аварийной ситуации;
— сообщение о статусе функции «разрешение/запрет на автономное сообщение о всех подобных сигналах».
Отслеживание истории сигналов/сообщений о возникновении аварийной ситуации. Оно включает запись моментов возникновения таких сигналов и их хранение в регистровом файле, регистры которого содержат все параметры сообщения о возникшей аварийной ситуации. Регистры могут быть считаны по запросу или периодически. OS определяет режим работы регистров: либо запись до заполнения с последующей остановкой или полным стиранием, либо непрерывная запись с циклическим возвратом от конца к началу с перезаписью старых событий.
Другие функции. Из них можно отметить, например, тестирование и регистрацию SDH оборудования.
Основные типы сообщений о возникновении аварийной ситуации. Для того, чтобы получить более полное представление о типах аварийных ситуаций, которые отслеживаются в сети SDH, они представлены в виде таб.3-1 [23], где в левом столбце помещены типы аварийных ситуаций, а в верхней строке — места их возможного возникновения. В ячейках таблицы помещен символ R, если требуется регистрация данного типа аварийной ситуации, или О, если такая регистрация не обязательна.
В таблице использованы следующие сокращения:
| TF | Сбой при передаче | RS | Регенераторная секция |
| LOS | Потеря сигнала | MS | Мультиплексная секция |
| LOF | Потеря фрейма | Path HOVC | Маршрут VC верхнего уровня |
| LOP | Потеря указателя | Path LOVC | Маршрут VC нижнего уровня |
| FERF | Сбой при приеме на удаленном конце | PPI/LPA | Плезиохронный физический интерфейс/адаптация маршрута VC нижнего уровня |
| TIM | Несовпадение идентификатора трассировки | ||
| SLM | Несовпадение типа сигнала | SETS | Хронирующий источник оборудования |
| LOM | Потеря мультифрейма | ||
| AIS | Сигнал индикции аварийного состояния | R1 | Для нагрузки, требующей индикации мультифрейма |
| Ехс | Слишком много ошибок | ||
| LTI | Потеря синхронизации на входе | R2 | Если подтверждается использование байта J2 в VC-11, VC-12 и VC-2 |
| SD | Ухудшение качества сигнала | ||
| SPI | Физический интерфейс SDH | R3 | Для байт-синхронного отображения |