2.9.2. Реализация интерфейса G.703

 

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

 

 

Из этой таблицы ясно, что полная реализация интерфейса G.703 для всех возможных скоростей и типов организации взаимодействия аппаратуры - дело весьма трудоемкое, поэтому производители ограничиваются реализацией указанного стандарта для конкретно используемой скорости пере- дачи, например, для скорости 2048 кбит/с в случае SDH канала 2 Мбит/с. Для скорости 64 кбит/с производители в большинстве случаев указывают и тип организации взаимодействия аппаратуры интерфейса, например, сонаправленный. Для сигналов со скоростями передачи пх6Е кбит/с, характерных для систем ISDN и передаваемых через мультиплексирующее оборудование иерархий, порожденных первичными скоростями 1544 и 2048 кбит/с, интерфейс, как отмечалось выше, должен иметь те же физические и электрические характеристики, что и соответствующий интерфейс 1544 кбит/с (для n=2, ...,23) или интерфейс 2048 кбит/с (для n=2, ...,31).

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

1 - цифровой двухчастотный двоичный код, преобразуемый в двухполярный трехуровневый код путем .=::---' последовательного изменения полярности каждого двоичного блока с отменой изменения на каждом восьмом блоке (октетное кодирование - пятишаговая процедура кодирования описана в стандарте G.703 [14]);

2 - большее значение соответствует ширине двойного импульса (логическая "1"), меньшее - ширине одинарного импульса (логический "0");

3 - большее значение рекомендуется использовать в случае повышенного уровня шума;

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

5- код B8ZS рекомендуется применять при использовании коаксиального кабеля, код 86ZS - при .,- использовании симметричной пары;

6 - большее значение соответствует допуску на область после среза импульса, меньшее - на область ': перед фронтом импульса;

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

8- большее значение соответствует использованию симметричной пары, меньшее - коаксиальному кабелю;

9 - используется симметричное поле допуска.

 

Заметим так же, что ширина импульсов приведена в мкс для скорости 64 кбит/с и в не для остальных скоростей.

Пользователь должен так же иметь ввиду, что указанные типы кода относятся только к интерфейсу, а не к линии в целом. Для электрических линий связи эти коды могут совпадать, для оптических- коды, как правило, не несовпадают в силу невозможности непосредственного использования биполярных кодов в оптическом кабеле. Например, при использовании кода HDB3 в оптических линиях связи в качестве интерфейсного могут использоваться также коды CMI, MCMI или код типа nBmB.

 

2.9.3. Подключение сети с интерфейсом G.703 к аппаратуре пользователя

 

Схема подключения сети, рассчитанной на использование интерфейса G.703, к аппаратуре пользователя зависит от наличия у пользователя входа с интерфейсом G.703, типа используемой среды распространения (электрический или оптический кабель) и от кабеля - его импеданса (75 или 100-120 om) и типа (коаксиальный кабель или симметричная пара проводов).

Эта схема наиболее проста, если используется электрический кабель, а пользователь имеет вход с интерфейсом G.703. Тогда подключение осуществляется либо коаксиальным кабелем с разъемом RG-59 (импеданс 75 ом), либо симметричной парой проводов (импеданс 100-120 ом) на коммутационную панель "под винт" - без специального разъема, либо с помощью разъемов DB-15, RJ-11, RJ-48Х. Как видно из таб. 2-5 симметричная пара используется только для частот не выше 6312 кбит/с. Если импеданс кабеля (пары проводов) пользователя не согласуется с импедансом линии, используется согласующий трансформатор (например, 120-симметричная пара/75-коаксиальный кабель).

Если в качестве среды распространения используется оптический кабель, то оптический сигнал преобразуется в электрический на входе аппаратуры пользователя и наоборот - на выходе аппаратуры пользователя. Преобразование осуществляется с помощью специального опто-электронного/электронно-оптического преобразователя - оптического модема (например, типа FLC - компании ADC Telecommunications). При этом на оптических входах/выходах используются специальные оптические разъемы (соединители) различного типа, например, $С, SMA, ST.

Если же аппаратура пользователя не имеет входа с интерфейсом G.703, а имеет входы с другими интерфейсами, то пользователь должен быть достаточно внимательным к указанной в документации конкретной спецификации интерфейса (если она есть), чтобы избежать проблем совместимости терминальной аппаратуры. В этом случае нужно использовать специальные конвертеры интерфейсов, которые позволяют состыковывать, например, локальные сети (LAN) с интерфейсами V.24, V.35, Х.21 с глобальными сетями (WAN) с интерфейсами G.703.

Такие конвертеры производят ряд компаний. Наиболее известной из них на нашем рынке является компания RAD Data Communications. Ограничимся, для примера, рассмотрением ее конвертеров, чтобы показать возможности преобразования интерфейсов [59]. Из набора производимых этой компанией конвертеровгинтерфейсов в таб.2-6 представлены те, что имеют G.703 на одной из сторон: стороне DCE (выходы WAN - верхние входы таб.2-6) или DTE (входы LAN - левые боковые входы таб.2-6). Ясно, что при использовании таких конвертеров для соединения с аппаратурой пользователя применяются соответствующие разъемы.

 

 

В заключение дадим некоторые пояснения к таб.2-б:

1- большинство конвертеров, указанных в таблице, являются не только конвертерами интерфейсов, но и конвертерами скоростей, согласующими скорости на входе со скоростями, требуемыми на выходе. Здесь вход соответствует стороне DTE, а выход - DCE;

2- для конвертера FCD-20, осуществляющего "обратное" конвертирование интерфейса G.703 в V 35 или в Х.21, суммарный поток входных каналов пх6Е на стороне G.703 не должен превышать 512 кбит/с. Такое конвертирование может потребоваться для стыковки мультиплексоров, имеющих выход G.703, с аппаратурой спутниковой связи, имеющей, например, только интерфейсы V.35 или Х.21.

Подводя итог сказанному о технологии SDH, можно констатировать, что в системах, использующих SDH устраняются практически все недостатки PDH. Системы SDH позволяют:

— использовать в качестве входных каналов практически все (кроме DSO) основные каналы доступа, используемые в PDH;

— определять положение любого стандартного канала доступа, инкапсулированного в соответствующий виртуальный контейнер, транспортируемый модулем STM-1, а также осуществлять его ввод/вывод в/из транспортного потока модулей STM-N без необходимости его сборки/разборки, в отличие от того, как это делалось в PDH;

— использовать эффективную систему маршрутизации, позволяющую автоматически управлять движением контейнеров между пунктами назначения;

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

— организовать в структуре фрейма внутренние служебный каналы с развитой системой сигнализации.

 

З. УПРАВЛЕНИЕ СЕТЬЮ: ФУНКЦИОНИРОВАНИЕ, АДМИНИСТРИРОВАНИЕ И ОБСЛУЖИВАНИЕ

 

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

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

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

 

3.1. ЧЕТЫРЕХУРОВНЕВАЯ МОДЕЛЬ УПРАВЛЕНИЯ СЕТЬЮ

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

 

3.2. СЕТЬ УПРАВЛЕНИЯ ТЕЛЕКОММУНИКАЦИЯМИ TMN И

 

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

 

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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

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

 

 

 

 

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

 

TMN включает ряд функциональных блоков, выполняющие следующие одноименные функции (в скобках даны термины, используемые в русских переводах стандартов ITU-Т): 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 (см. п.3.2.2.2);

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-Т М.3100 [62]; эти точки делятся на два типа:

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

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

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

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

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

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

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

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

 

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

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

 

 

Внешний доступ к ТМИ

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

 

 

 

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

 

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

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

 

 

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

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

 

 

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

 

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

 

 

 

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

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

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

 

Протоколы ТМИ

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

практически всегда, так как транспорт сообщений TMN осуществляется протоколами сетевого уровня.

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

 

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

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

 

 

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

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

 

3.3. ОБЩАЯ СХЕМА УПРАВЛЕНИЯ СЕТЬЮ SDH

 

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

 

 

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

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

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

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

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

 

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

 

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

 

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

 

 

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

— несколько адресуемых NE могут располагаться в одном месте, доступ к которому осуществляется через шлюзовые элементы сети GNE, например 6МЕ» - GNEG,'

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

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

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

 

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

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

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

 

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 НОVС     Маршрут VC верхнего уровня

LOP Потеря указателя                                                         Path LOVC     Маршрут VC нижнего уровня

FERF Сбой при приеме на удаленном конце                        PPI/LPA    Плезиохронный физический интерфейс/ адаптация маршрута VC нижнего уровня

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

SLM Несовпадение типа сигнала                                      SETS                Хронирующий источник                синхронного оборудования           

 

LOM Потеря мультифрейма                                  

AIS Сигнал индикации аварийного состояния               R1           Для нагрузки, требующей индикации   мультифрейма

Exc Слишком много ошибок

LTI Потеря синхронизации на входе                                R2           Если подтверждается использование байта J2 е VC-11, ЧС-12 и VC-2

 

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

SPI Физический интерфейс SDH                                       R3        Для байт-синхронного отображения

 

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

 

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

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

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

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

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

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

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

 

 

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

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

 

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

Общая стратегия их использования описана в рекомендациях ITU-Т Rec. М.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 наступает тогда, когда обнаруживается последовательность из Х или больше SES. При обнаружении этого события последовательность прерывается фиксацией начала недоступного интервала времени, в течение которого CSES не регистрируются. Конец этого интервала фиксируется тогда, когда регистрируется секунда не являющаяся SES. По крайней мере 6 CSES (вместе с датами появления первых SES в последовательности) должны при этом запоминаться. Значение Х устанавливается 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. Обзор используемых протоколов

 

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

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

Физический. уровень - Протокол DCC не оговорен. ОСС представляет физический уровень,

причем DCC регенераторной секции работает для передачи сообщений как канал 192 кбит/с (байты SOH D1-03), а DCC мультиплексной секции - как канал 576 кбит/с (байты SOH 04-012).

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

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

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

 

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

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

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

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

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

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

 

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) Х.25, определяются функцией сведения, зависящей от подсети (SNDCF), описанной в стандарте ISO 8473 [81].

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

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

 

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

 

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

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

 

 

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

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

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

 

 

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

— К интерфейсам Оз могут подключаться 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 c режимом установления соединений;

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]. Скорости передачи, поддерживаемые интерфейсом Оэ, зависят от типа CLNS. Для CLNS1 она составляет 1, 10 Мбит/с или выше. Для CLNS2 соответствуют ряду: 1200, 2400, 4800, 9600, 19200 и 64000 бит/с (допустимо в течение некоторого переходного периода использование скоростей 48000 и 56000 бит/с).

Для CLNS1 в качестве физической среды распространения сигнала используют коаксиальный кабель, экранированную витую пару или ВОК. Для CLNS2 в качестве соединительных разъемов допустимо использовать те, что поддерживают интерфейсные протоколы Х.21, Х.21bis и интерфейсы серии V. К этим интерфейсам из широко известных относятся Х.21 и V.35 и из не очень широко известных ISO 2110 (Х.21bis), ISO 2593 (Х.21, Х.21bis), ISO 4902 (Х.21bis) и ISO 4903 (Х.21) [104,105]. Описание сигналов на контактах и их соответствие сигналам интерфейсов Х.21 и Х.21bis также приведены в рекомендации ITU-Т 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-Т М.3300 [66].

 

3.4. ПРАКТИЧЕСКИЕ МЕТОДЫ УПРАВЛЕНИЯ СЕТЬЮ SDH

 

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

 

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

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

 

 

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

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

 

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

 

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

 

 

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

 

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

 

Каждый узел сети управления должен иметь свой адрес точки доступа сетевого сервиса NSAP.

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

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

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

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

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

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

 

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

Внутри одной области начальная часть домена IDP и адрес области АА (длиной в 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), заголовки SOH и POH фрейма STM-N имеют достаточно большую резервную емкость, которая может быть использована для формирования различных служебных каналов. Общий объем заголовка составляет 90 (81+9) байт. Использование каждого байта эквивалентно созданию 64 кбит/с канала. Все указанные байты могут быть разделены на три типа (рис.3-15):

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

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

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

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

 

 

 

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

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

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

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

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

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

 

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

 

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

 

 

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

 

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

 

Среди хронирующих источников наиболее универсальным и точным является мировое скоординированное время UTC. Для его трансляции используются спутниковые системы LORAN-С и глобальная система позиционирования GPS. Традиционные системы приема UTC требуют значительных затрат и используются как правило в центрах спутниковой связи. Однако в связи с широким развитием GPS была разработана альтернатива первичным эталонным источникам PRS - технология локальных первичных эталонов LPR, основанная на использовании UTC для подстройки частоты. Многие

телефонные компании используют эту технологию в местах развертывания GPS для создания альтернативы таймерам класса TNC на транзитных узлах. На таких узлах в качестве таймеров TNC устанавливаются улучшенные рубидиевые часы. В комбинации с технологией LPR использование синхронизации от UTC позволяет получать локальные первичные эталоны существенно перекрывающие требования по точности 10 ", устанавливаемые стандартами ITU-Т и ETSI для первичных эталонных таймеров.

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

 

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

 

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

 

 

 

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

 

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

 

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

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

 

 

 

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

 

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

 

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

Элемент-менеджеры могут быть реализованы на различных компьютерных платформах в том числе и на IBM PC совместимых компьютерах под управлением различных операционных систем, на- пример, Windows, Windows 95, Windows NT. Информация, получаемая в процессе работы элемент- менеджера, может храниться в файле или в базе данных, используемой менеджером сети SDH. Основное окно ЕМ, кроме стандартных для оконных интерфейсов опций - Options, Window, Help, содержит по крайней мере следующие опции: Node - для работы с узлом или элементом сети, Date - для отображения хранящейся информации, 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 Мбит/с) делают только некоторые производители, а для ЧС-2, как правило, по запросу пользователя, то на уровне VC-4 и VC-12 (для европейских потребителей) кросс-соединение реализовано практически на любом типе такого оборудования. Режим такого соединения - двунаправленный.

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

 

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

Если рассмотреть в качестве образца сетевой менеджер ENM компании ECI [122], то он реализован на базе рабочей станции SUN SPARC по управлением 0$ 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, объединяет все шесть узлов (А-F) ячеистой сети, другая - использует каналы Ethernet, объединяет три станции узла А (А1- АЗ). К последней из них - АЗ, присоединен узловой менеджер на базе 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 = О. Эти адресные поля остаются постоянными для всех узлов рассматриваемой в данном примере сети SDH.

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

 

 

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

 

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

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

 

 

Списки источников синхронизации, выбираемых по номеру приоритета для каждого узла, сведены в таблицу 3-7. Каждый узел, кроме узлов А1, А2, АЗ, имеет по три источника синхронизации с номерами, соответствующими порядку приоритета (т.е. 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. Е.164 [139]. Он должен содержать как минимум имена исходного узла и узла назначения, символьный код виртуального контейнера (например, А, В, С и D соответствуют VC-12, ЧС-2, VC-3 и VC-4), номер тайм-слота терминального кросс-коммутатора, осуществляющего вывод заданного виртуального контейнера. Описать это более подробно можно только на примере конкретного оборудования. Идентификаторы TTI позволяют контролировать корректность установки таблицы кросс-коммутации у кросс-коммутаторов на всем пути следования виртуального контейнера.

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

 

 

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

 

 

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

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

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

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

 

4. СТАНДАРТЫ И ТЕРМИНОЛОГИЯ СИНХРОННЫХ СЕТЕЙ

 

4.1. СТАНДАРТЫ ЦИФРОВЫХ СИНХРОННЫХ СЕТЕЙ

 

 

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

Стандарты, описывающие принципы организации и функционирования синхронных цифровых сетей связи, первоначально разрабатывались в основном двумя организациями: Американским национальным институтом стандартов (Комитет Т1Х1) и Международным Консультативным Комитетом по Телеграфии и Телефонии. Последний представил свои результаты в 1988 году в виде серии рекомендаций (де-факто стандартов) G.700-G.7хх, рассмотренных на Пленарной Ассамблее Международного союза электросвязи в 1988 году и опубликованных в 1989 году в так называемой Синей книге - СС!ТГ Blue Book. В настоящее время разработкой этих и сопутствующих стандартов занимаются несколько организаций:

— Американский национальный институт стандартов - ANSI;

— Объединение Европейских администраций почт и связи - СЕРТ;

 — Международный консультативный комитет по радио и телевидению - CCIR (МККРТ);

 — Международный консультативный комитет по телеграфии и телефонии - CCITT (MKKTT), до 28 февраля 1993 года;

— Международный союз электросвязи - ITU (МСЭ), куда входили комитеты CCIR и CCITT, имеет с 1 марта 1993 года сектор стандартизации в области электросвязи ITU-Т (до 28 февраля 1993 года интересующие нас рекомендации выходили под эгидой CCITT, а с 1 марта 1993 года стали выходить как рекомендации ITU-Т);

— Сектор по стандартизации Международного союза электросвязи - ITU-Т (МСЭ-Т), начиная с 1 марта 1993 года;

— Европейский институт стандартов в области связи - ETSI;

— Международная электротехническая комиссия - IEC (МЭК);

— Международная организация по стандартизации - ISO.

Кроме этого корпоративные стандарты разрабатываются также рядом компаний, например, Bellcore, AT8T и другими.

Первая попытка разработки стандартов синхронных оптических сетей относится к 1984 году. Первый стандарт таких сетей "Syntran" базировался на скорости 45 Мбит/с (канал ТЗ), в это же время AT&T предложила использовать в качестве стандартной скорость 150 Мбит/с. В 1985 году Bellcore внесла в комитет T1X1 предложение на проработку стандарта синхронной оптической сети SONET. В 1986 году стандартом SONET заинтересовался комитет СС!ТТ. Одна из его исследовательских групп (SG XVIII) и занялась разработкой стандарта SDH. Первоначально порождающие скорости SONET и SDH были разными и нецелократными (50 и 155 Мбит/с). В феврале 1988 года было принято согласованное решение по начальной скорости оптической несущей ОС (ОС-1 = 51.84 Мбит/с), при ко- торой скорость синхронного транспортного модуля STM-1 равная 155.52 Мбит/с оказалась равной утроенной скорости ОС-1 или скорости ОС-З. Это решение привело к окончательной доработке технологии SDH, оформленой в виде трех рекомендаций G.707[16], G.708[17] и G.709[18], принятых в 1988 году и опубликованных в 1989 году в "Синей книге".

Рекомендации CCITT, получив всеобщее признание, стали фактически международными стандартами - отправным пунктом для разработчиков аппаратуры SDH. В 1990-1997 годах комитет CCITT, а затем его преемник - сектор по стандартизации ITU-Т, продолжили разработку новых стандартов по SDH, в том числе и подвергая ревизии старые стандарты. В настоящее время группа стандартов, прямо или косвенно связанных с SDH, уже насчитывает несколько десятков. Есть смысл хотя бы перечислить их, тем более, что выше были описаны только основные из них.

 

 

4.1.1. Краткий обзор стандартов синхронных цифровых сетей

 

В этом обзоре мы ограничимся только рекомендациями ITU (МСЭ) серии G, но приведем не только стандарты по технологии SDH, но и некоторые сопутствующие стандарты по технологии PDH и волоконно-оптическим кабелям (ВОК).

 

 

Группа рекомендаций: G.650 [141], G.652 [142], G.653 [143], G.654 [144], G.655 [145] - описывает характеристики одномодовых ВОК, которые широко используются в сетях SDH. Характеристики отечественных оптических кабелей связи можно найти в [33], где приведены также ссылки на ТУ на отчественные оптические кабели.

Группа рекомендаций: G.661 [146], G.662 [147], G.663 [148], G.681 [149] - описывает характеристики таких оптических компонентов и подсистем линейных сетей 80Н как оптические усилители.

Основная группа рекомендаций серии G.70х: G.702 [13], G.703 [14], G.707 [16], G.708 [17], G.709 [18], описывающая стандартные скорости иерархий PDH (G.702) и соответствующие им интерфейсы (G.703), а также стандартные скорости SDH иерархии (G.707), сетевой интерфейс и структуру мультиплексирования (G.708, G.709) - была достаточно подробно рассмотрена выше. Нужно иметь ввиду только, что самая последняя версия рекомендации G.707 [150] 1996 года заменяет сразу три рекомендации G.707, G

.708 и G.709 версии 1993 года.

Рекомендация G.773 [89], описывающая стек протоколов для интерфейса О, также подробно освещена в тексте выше.

Новая группа рекомендаций: G.774 [19], G.774.1 [151], G.774.2 [152], G.774.3 [153], G.774.4 [154], G.774.5 [155], G.774.7 [156] - посвящена информационной модели управления сетью SDH и ее элементами. Она описывает классы объектов сети управления TMN, требуемые для управления элементами и подсистемами сети SDH, а также для мониторинга их рабочих характеристик.

Группа рекомендаций: G.780 [157], G.781 [20], G.782 [21], G.783 [22], G.785 [158] - описывающих терминологию и оборудование сетей SDH, его типы, характеристики и выполняемые функции, была частично описана выше. Однако формализация логических функций, выполняемых оборудованием SDH, изложенная в рекомендации G.782, описана несколько более подробно ниже в п. 4.1.2. данного параграфа.

Рекомендация G.784 [23], посвященная системе управления сетью и оборудованием SDH, достаточно подробно описана в тексте выше.

Рекомендация G.803 [159] посвящена формализованному рассмотрению транспортных функций архитектуры сети SDH, основных функций защиты и самовосстановления сетей SDH, а также проектированию топологии сети синхронизации и взаимодействия сетей PDH и SDH. Рекомендация считается одной из основополагающих при рассмотрении проблем синхронизации SDH сетей. В ней вводится классификация цифровых сетей по степени поддержания синхронности распространения цифровой последовательности. Эта классификация основана на понятии "проскальзывание" (или "слип" (slip)). Его суть в том, что несинхронность работы локальных хронирующих источников, синхронизируемых различным способом (или вообще работающих автономно), приводит к тому, что частоты входных цифровых последовательностей и тактовой синхронизации в местах стыка границ участков, обслуживаемых разлитыми хронирующими источниками, отличаются (хотя и на достаточно малую величину) друг от друга. Это приводит к появлению небольшой разностной скорости, или относительному движению, или проскальзыванию одной последовательности относительно другой. Накапливаясь за определенный промежуток времени, оно (движение) приводит к временному срыву синхронизации. Определенное влияние на этот процесс оказывает как дрожание фазы (jitter), так и медленный дрейф фазы (wander) казанных после последовательностей

Все сети, согласно рекомендации G.803, делятся на:

— синхронные, в которых (в идеале) отсутствует относительное проскальзывание (или "слипы") цифровых последовательностей на входах каналов доступа мультиплексоров PDH и SDH,

- псевдосинхронные, e которых регламентируется низкий уровень проскальзывания (например, не больше, чем 1 слип/70 дней [160]),

- плезиохронные, в которых допускается средний уровень проскальзывания (например, не больше, чем 1 слип/17 часов [160]),

- асинхронные, в которых допускается высокий уровень проскальзывания (например, не больше, чем 1 слип/7 сек [160]).

Указанная классификация принята за основу при создании Руководящих технических материалов (РТМ) [160], в которых рассматриваются вопросы формирования сети синхронизации для Взаимоувязанной сети связи (BCC) РФ [137]. В частности, предлагается разбиение всей ВСС на 4 региона, в которых предполагается использовать описанную выше технологию принудительной синхронизации, использующей иерархическую структуру хронирующих источников в сочетании с парами "ведущий/ведомый" источников. При этом предполагается, что сеть ВСС РФ по классу синхронизации должна быть не хуже плезиохронной. Нужно заметить, что работы в этом направлении находятся пока на этапе становления, а ситуация в регионах такова, что цифровая сеть может классифицироваться в

целом больше как асинхронная.

Рекомендация G.803, в части требований к вторичным хронирующим источникам для оборудования SDH, поддержана новой рекомендацией G.813 [163]. В рекомендации G.804 [161] описан метод передачи АТМ ячеек по существующим сетям PDH. В частности рассмотрен метод отображения ячеек на структуру кадров PDH для всех скоростей передачи PDH грибов европейской и американской иерархий и скорости 97.728 Мбит/с японской иерархии в соответствии с рекомендацией G.702 [13]. Метод отображения ячеек на структуру полезной нагрузки фреймов $ТМ технологии SDH рассмотрен в рекомендации G.709 версии 1993 года [18] и частично освещен в [162].

Рекомендация G.825 [164] описывает схемы управления дрожанием фазы (jitter) и дрейфом фазы (wander) цифровых последовательностей в сетях SDH. Для измерения этих характеристик, а также других характеристик SDH оборудования, существует ряд приборов ведущих фирм, рассмотрение которых выходит за рамки данной книги.

Рекомендация G.831 [123] дополняет рекомендацию G.803 в части описания требований к административному управлению разбитой на уровни сети передачи. Она определяет процесс управления маршрутом (трактом) при использовании схем защиты, в частности те его аспекты, которые требуют поддержки при пересечении границ административных доменов (см. п.3.4.1.2).

В рекомендации G.832 [124] рассмотрена возможность транспортировки элементов структуры мультиплексирования SDH - TU-12, VC-З, TUG-2 и TUG-З, через сети PDH путем их размещения в поле полезной нагрузки фреймов, соответствующих кадрам стандартных каналов ЕЗ (34 Мбит/с), DS3 (45 Мбит/с), DSJ4 (98 Мбит/с) и Е4 (140 Мбит/с) европейской, американской и японской PDH иерархий (см. п.1.5.1.). Эти решения позволяют гибко сочетать сегменты PDH и SDH сетей при создании

единой синхронной сети связи.

В рекомендации G.841 [125] рассмотрены типы и характеристики самовосстанавливающихся топологий архитектуры сетей SDH (см. п.2.5.).

В новой рекомендации G.861 [126] рассмотрены вопросы интеграции спутникового, радиорелейного и наземного (кабельного) сегментов транспортных сетей SDH. В рекомендациях G.957 [24] и G.958 [25] рассмотрены оптические интерфейсы оборудования и систем SDH (G.957), а также цифровые линейные системы SDH (G.958). В рекомендации G.957 представляет интерес широко применяемая классификация оптических интерфейсов, основанная на вариантах практического использования ВОК внутри станции или для стандартных короткой или длинной межстанционных регенераторных секций (см. п.2.6.3).

 

4.1.2. Систематизация логических функций оборудования SOH

 

Оборудование сетей SDH, рассмотренное выше, - мультиплексоры, кросс-коммутаторы, регенераторы и функциональные блоки, используемые в них, например, грибные интерфейсные блоки, блоки коммутации, управления, питания и т. д., выполняли определенные функции обработки цифрового потока или поддержания работоспособности системы в целом. На определенном этапе развития сетей SDH, главным образом в связи с формализацией задач управления такими сетями, появилась необходимость определить набор логических функций, выполняемых оборудованием SDH и провести их систематизацию. Это было сделано в рекомендации G.782 [21], где была приведена схема мультиплексирования (рис.4-1), составленная из обобщенных логических блоков, выполняющих определенную логическую функцию. Эта рекомендация была одобрена в июле 1990 года [3], затем подверглась существенной доработке в январе 1994 года [21] и была окончательно опубликована в феврале 1995 года.

 

 

 

Сокращенные обозначения функций, используемые на рисунке, расшифрованы ниже.

HCS контроль соединений на уровне виртуального контейнера верхнего уровня

НОА сборка виртуального контейнера верхнего уровня

HOI интерфейс сборки виртуального контейнера верхнего уровень

HPA адаптация к маршруту виртуального контейнера верхнего уровня

HPC соединение нескольких виртуальных контейнеров верхнего уровня

HPOM мониторинг POH виртуального контейнера верхнего уровня

HPT начало/окончание маршрута виртуального контейнера верхнего уровня

HUG генерация незагруженного виртуального контейнера верхнего уровня

LCS контроль соединений на уровне виртуального контейнера нижнего уровня

LOI интерфейс сборки виртуального контейнера нижнего уровня

LPA адаптация к маршруту виртуального контейнера нижнего уровня

LPC соединение нескольких виртуальных контейнеров нижнего уровня

LPOM мониторинг POH виртуального контейнера нижнего уровня

LPT начало/окончание маршрута виртуального контейнера нижнего уровня

LUG  генерация незагруженного виртуального контейнера нижнего уровня

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

MSA адаптация на уровне мультиплексной секции

MSP защита мультиплексной секции

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

N  опорная точка канала DCC для регенераторной секции

ОНА функция доступа к заголовку SOH

P  опорная точка канала DCC для мультиплекс- ной секции

PPI физический интерфейс сигнала PDH

RST  начало/окончание регенераторной секции

S опорная точка схемы представления системы административного управления

SEMF функция управления синхронным оборудованием

SETPI  физический интерфейс хронирующего источника синхронного оборудования SETS хронирующий источник синхронного оборудования

SPI  физический интерфейс сигнала SDH

T опорная точка источника синхронизации

TTF  функция окончания транспорта виртуального контейнера

U опорная точка доступа к заголовку SOH

Y опорная точка формирования статуса синхронизации

 

Замечание: SPI при этом имеет три опции: электрическую или оптическую внутри станции и оптическую между станциями.

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

 

4.2. ТЕРМИНОЛОГИЯ ЦИФРОВЫХ СЕТЕЙ

 

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

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

Альтернативная терминология отечественных специалистов по электросвязи, зародившаяся еще до широкого развития компьютерных сетевых технологий [166], продолжала существовать в рус- ских переводах стандартов CCITT и ITU-Т и была отражена в PTM [12].

 

4.2.1. Истоки появления новой терминологии

 

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

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

1962 - начало эксплуатации компанией Bell System первой коммерческой системы цифровой телефонии с каналами DSO (64 кбит/с), мультиплексируемыми в канал Т1 (1.544 Мбит/с). Она положила начало созданию PDH иерархии;

1963 - появление ЭВМ 3-гo поколения - IBM System-360 с байт-ориентированной структурой данных и "каналом" для приема/передачи и мультиплексирования низкоскоростных потоков данных, упрощающим схему организации сетей ЭВМ - послужило мощным стимулом и основой для развития первых компьютерных сетей;

1970-72 - появление ЕС-ЭВМ (отечественного аналога IBM System-360) и публикация отечественных стандартов на аппаратуру оконечного оборудования данных ООД, аппаратуру окончания канала данных АКД и систем передачи данных СПД - послужило стимулом и основой для создания отечественных компьютерных сетей;

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

1981 - начало систематических работ по локальным сетям на основе ПК;

1983 - разработка базовой модели взаимодействия открытых систем - OSI (ВОС), открыв- шей возможности стандартизации и использования сетевого оборудования различных производителей в одной сети;

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

 

Этот перечень показывает, что развитие компьютерных сетей и цифровых сетей связи, начиная с 1962 г., происходит практически параллельно, причем так, что отечественная терминология в обоих случаях (в части передачи данных) остается достаточно единообразной (с приматом терминологии сетей связи) вплоть до 1986 года, в основном благодаря усилиям Госстандарта.

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

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

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

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

В этой ситуации различие терминологий стало объективным тормозом становления новых сетевых технологий, причем не "у них", разрабатывающих эти технологии, а у нас, в России, лишенной в эти годы не только достаточного количества ПК, для организации ЛВС, но и (что более важно) отечественной литературы по цифровым сетям. У нас, где один термин, например, frame в зависимости от технологии переводится специалистами то как цикл, то как кадр, то как посылка или пакет, но не как фрейм.

Отсутствие отечественной терминологии в области новых информационных технологий привело к широкому использованию русских "калек" и английской аббревиатуры в качестве новых сетевых терминов, что дало возможность по крайней мере избежать какого-бы то ни было непонимания в среде специалистов по локальным сетям. Сейчас можно сказать, что терминология традиционных локальных сетей (Token Bus - ARCnet, Ethernet, Token Ring и FDDI) практически устоялась. Аналогичная ситуация характерна и для других новых ЛВС технологий Switched Ethernet и Fast Ethernet.

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

 

4.2.2. Некоторые предложения по выбору терминологии в технологиях PDH и SDH

 

Приведу некоторые положения, которыми руководствовался автор при выборе нового термина или его переводе с языка оригинала, и остановлюсь на некоторых спорных терминах. Так как все новые сетевые термины пришли к нам "от них", то проблема терминологии сводится к проблеме их заимствования или адекватного перевода. Было бы логично при этом придерживаться ряда принципов:

1 - При выборе варианта перевода нужно следить, чтобы "множество возможных толкований" данного варианта не пересекалось или минимально пересекалось с аналогичным множеством у других терминов.

2 - Вариант перевода или термин должен сохранять этимологию исходного (переводимого) термина. 3 - При выборе варианта перевода следует учитывать сложившуюся практику перевода, если она не противоречит другим принципам.

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

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

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

— октет - байт. В обоих случаях это поле длиной в восемь бит, обрабатываемое как единое целое (термин октет в значении 8-битный (а не 7-битный) байт появился на рубеже 50-60 годов в связи с развитием ИКМ). Практически все стали использовать термин байт.

— стык - интерфейс. В обоих случаях это совокупность технических и программных средств, используемых для сопряжения устройств или систем, или программ. Практически везде стал использоваться термин интерфейс, как более широкое понятие, используемое в связке с поясняющими его определениями: логический интерфейс, физический интерфейс, программный интерфейс (в [127], например, приведено 28 таких связок).

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

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

1 - frame - переводится или как кадр, или как цикл, или как фрейм. Во всех случаях это блок данных фиксированной длины, представляемый либо в виде одномерного последовательного поля (технологии Frame Relay, PDH), либо в виде двумерной таблицы (технология SDHj. Предлагается использовать термин кадр (для одномерного последовательного поля), либо фрейм (для двумерной таблицы и вообще для технологий PDH и SDH, где они достаточно тесно переплета- ются). В технологиях PDH и SDH традиционно для обоих представлений frame переводят как "цикл". Однако цикл - понятие временное: "Цикл - совокупность явлений, процессов, составляющая кругооборот в течение известного промежутка времени", [138, с.1492]. Фрейм - понятие пространственное. Когда пишут, что цикл в SDH представляет собой структуру, состоящую из 9 строк и 270 столбцов, то, вольно или невольно, определяют временное понятие, как пространственное, что, по сути, является ошибкой. В то же время нормально звучат связки типа: "цикл повторения фрейма составляет ...", где временное понятие используется в качестве указания на периодичность повторения пространственного понятия.

Использование термина фрейм, позволяет избавиться и от еще одного непривычного термина сверхцикл, предлагаемого в качестве эквивалента исходного термина multiframe (мультифрейм). Приставка "мульти" напоминает о том, что мультифрейм получен путем мультиплексирования фреймов. Приставка "сверх", напротив, не соответствует этимологии исходного термина.

2 - trib, tributary - переводится как компонентный сигнал, подчиненный сигнал [12] или нагрузка, поток нагрузки [165]. Вариант, используемый автором - триб. Последний термин базируется на русской кальке триб при переводе слова trib, tributary, к нему примыкает и группа производных терминов с прилагательным грибный: грибный блок (tributary unit) грибный интерфейс (tribuQry interface). Такой перевод кажется наиболее адекватным и вовсе не случайным. Разработчики технологий PDH и SDH, используя термин trib (tributary), хотели подчеркнуть тот факт, что это не просто произвольная составляющая - компонентный сигнал, участвующая в схеме мультиплексирования, а такая составляющая, которая соответствует (подчиняется) иерархии PDH (PDH trib - триб PDH) или иерархии SDH (SDH trib - триб SDH). C этой точки зрения термин подчиненный сигнал сохраняет этимологию исходного термина. Однако он и основанные на нем связки типа "интерфейс подчиненного сигнала" оказываются громоздкими по сравнению с кратким и четким термином "грибный интерфейс". Как и в предыдущем случае "русские кальки" - триб, грибный блок, грибный интерфейс звучат проще, полностью сохраняют этимологию исходных терминов и что не менее важно нормально воспринимаются специалистами по этим технологи- ям, воспитанными на оригинальных публикациях рекомендаций CCITT (ITU-Т).

Что касается замечаний, что правильнее переводить трибутарий (вместо триб) и соответственно трибутарный (вместо грибный), то замечу, что триб (trib) - грамматически правильная краткая форма слова tributary (трибутарий), см., например [130, р.2440]. Именно ее в силу краткости автор и предлагает использовать в качестве термина.

Для законченности рассуждений, дадим некоторые определения:

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

- триб PDH - триб, скорость передачи которого соответствует одной из PDH иерархий (например, трибы 2, 8, 34, 140 Мбит/с соответствуют европейской иерархии PDH);

- триб SDH - триб, скорость передачи которого соответствует SDН иерархии (например, трибы 155, 622, 2488, 9952 Мбит/с);

- гриб $0ИЕТ - триб, скорость передачи которого соответствует иерархии SONET (например, трибы 52, 104, 155, 207 и т.д. до и х 51.84 Мбит/с).

Чтобы показать разницу между понятием компонентный сигнал и триб, укажем, например, что сигнал 512 кбит/с (так называемый дробный Е1) может быть компонентным сигналом мультиплексора, но не может быть трибом, так как не соответствует ни PDH, ни SDH, ни SONET иерархиям.

Производные термины:

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

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

3 - alarm - переводится как тревожный сигнал, сигнал тревоги [131], сообщение об отказе [126], аварийн(ое]ый) состояние/сигнал [132]. Широко используется производный термин- Alarm Indication Signal (AIS) - сигнал индикации аварийного состояния. В книге автором используется перевод слова alarm как "аварийное состояние", хотя и его перевод как "аларм", можно было бы обосновать не только широким использованием его в жаргоне "сетевиков", но и потому, что он краток, соответствует оригиналу и легко связывается для создания адекватных оригиналу производных терминов, например, сигнал аларма, индикатор аларма, цветокодировка аларма, статус аларма, а также потому, что это более широкое понятие. Оно не обязательно означает аварийное состояние в нашем понимании или не всегда является сообщением об отказе. Образно говоря, аларм понятие цветное, а не черно-белое, как сигнал тревоги. Оно отображает одно (текущее, или привязанное к какому-то (прошедшему) моменту времени) состояние из множества состояний системы. Алармы можно игнорировать (фильтровать) или группировать для формирования обобщенного показателя.

4 - unit - переводится как блок в связках типа: AU - административный блок, AUG - группа административных блоков, TU - грибный блок, TUG - группа грибных блоков; использование для всех вышеназванных понятий термина модуль, как это сделано в [165], трудно оправдать, хотя-бы потому, что в оригинале стандартов используются оба термина: блок и модуль, причем последний используется только для STM - синхронного транспортного модуля. Кроме того, модуль - за- конченное образование, тогда как блок - его составная часть. Как известно, в SDH иерархии TU, TUG, AU, AUG - суть логические блоки (не существующие самостоятельно), из которых и собирается физически существующий транспортный модуль STM. Для других терминов, используемых автором, все необходимые определения терминов интересующиеся могут найти в соответствующих стандартах. Наиболее полно они отражены в [133,134,135].

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

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

— кадр - блок данных постоянной (фиксированной) длины, представленный в одномерном виде (АТМ, FDDI, PDH);

— фрейм - блок данных постоянного (фиксированного) размера, представленный в двумерном виде или развернутый в виде одномерного блока с сохранением структуры двумерного (PDH, SDH);

— пакет - блок данных переменной длины, представленный в одномерном виде (Arcnet, Ethernet, FDDI, Token Ring, Frame Relay, Х.25, ISDN);

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

— контейнер - блок данных, имеющий ряд фиксированных размеров, представленный в двумерном виде (SDH).

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

 

ЗАКЛЮЧЕНИЯ

Автор постарался, как ему кажется, собрать все наиболее важное, необходимое для понимания данной технологии, и придать книге некий законченный вид, чтобы предложить ее вниманию читателя. За прошедший с момента издания год разошлись два тиража книги, свидетельствуя о том, что книга нашла одобрение у читателей. Автор благодарен им за высказанные замечания, часть из которых удалось оперативно учесть уже в этом исправленном третьем тираже первого издания.

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

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

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