Файл: Book2 Full.doc

Механизм защиты применяется также и по отношению к С-пути самого протокола защиты. В отличие от любых других протоколов V5 сообщения протокола защиты передаются дважды, по разу в каждом из двух трактов, которые его обслуживают. Структура этих сообщений приведена на рис. 8.6. Заголовок сообщений протокола защиты V5.2 начинается с дискриминатора протокола, общего для всех сообщений V5, а заканчивается информационным элементом типа сообщения, который определяет одно из восьми возможных сообщений протокола защиты (таблица 8.8).

Первые пять сообщений в таблице 8.8 связаны с функциями переключения и управляют соответствием логических С-каналов и физических канальных интервалов. Оставшиеся три сообщения связаны с ошибками протокола и с перезапуском средств нумерации сообщений. Сообщения переключения и сообщения об ошибках в протоколе последовательно нумеруются, номер сообщения содержится в информационном элементе Sequence-number (порядковый-номер). Сообщения перезапуска средств нумерации передаются в качестве команды или подтверждения, если обнаруживаются нарушения нумерации других сообщений. Канальный интервал, к которому эти сообщения относятся, идентифицируется информационным элементом Physical-C-channel (физический-С-канал).

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

Команды, которые переключают логические С-каналы на другие физические канальные интервалы, передаются только со стороны АТС, поскольку только АТС располагает сводной таблицей отображения логических связей на физические. Если переключение было инициировано операционной системой (ОС) АТС, то станция передает сообщение OS_SWITCH_OVER_COM, подавая команду сети доступа переключить указанный логический С-канал на указанный канальный интервал. Станция может также передать сообщение SWITCH_OVER_COM, чтобы выполнить ту же самую функцию в случае, когда не нужно указывать, что переключение было инициировано операционной системой.

По мнению [83], с которым автор солидарен, нет видимой причины информировать сеть доступа о том, кто инициировал переключение.

Примеры сценариев переключения приведены на рис.8.7.

Сеть доступа передает сообщение SWITCH_OVER_ACK, чтобы информировать АТС о выполнении команды переключения логического С-канала на новый канальный интервал. Если сеть доступа не может выполнить команду, она отвечает сообщением SWITCH_OVER_REJECT.

Сеть доступа может использовать сообщение SWITCH_ OVER_REQ, чтобы запросить АТС переключить указанный логический С-канал на указанный канальный интервал.

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

Обе стороны интерфейса V5.2 ожидают получения сообщений с очередным порядковым номером. Если в получаемом одной из сторон интерфейса сообщении происходит «скачок» нумерации, то регистрируется сбой и к противоположной стороне направляется сообщение RESET_SN_COM, чтобы информировать ее о том, что нумерацию сообщений нужно начать заново. Сторона, которая получает сообщение RESET_SN_COM, отвечает сообщением RESET_SN_ACK, подтверждающим, что соответствующие счетчики установлены в «0». Напомним, что нумеруются сообщения переключения и ошибок в протоколе, т.е. первые шесть из восьми сообщений протокола защиты.

Сообщения перезапуска средств нумерации не содержат специализированных информационных элементов и не привязаны к отдельным логическим С-каналам. Поэтому обязательный информационный элемент «Идентификатор логического С-канала» (байт 2 и байт 3 рис. 8.6) в этих сообщениях имеет значение «0» (т.е. все биты должны быть установлены в «0»).

Протокол защиты V5.2 предусматривает один тип сообщения об ошибке в протоколе — сообщение PROTOCOL_ERROR, которое передается от сети доступа к АТС и содержит информационный элемент Protocol-error-cause (Причина-ошибки-в-протоколе), указывающий тип ошибки. Типы ошибок приведены в таблице 8.9. Как и все типы сообщений переключения, сообщения PROTOCOL_ERROR последовательно нумеруются с использованием информационного элемента «Порядковый-номер». Подобно сообщениям отказа в переключении, они должны указывать на происхождение проблемы, но, в отличие от сообщений отказа в переключении, не должны идентифицировать канальный интервал.

8.4. Протокол управления

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

Сообщения протокола управления интерфейса V5 идентифицируются информационным элементом «тип сообщения» в общем заголовке. Предусматривается четыре типа сообщений. Два из них, PORT_CONTROL и COMMON_CONTROL, являются инициирующими сообщениями, которые управляют портами и общими функциями, соответственно. Два других типа сообщений - PORT_CONTROL_ACK и COMMON_CONTROL_ACK - являются подтверждающими. Для сообщений общего управления адрес сообщения в заголовке берется из общего адресного пространства V5 согласно таблице 6.3 главы 6 этой книги. Для сообщений управления, ориентированных на порт, адрес определяется соответствующим портом ТфОП или ISDN. В заголовке сообщений управления имеет место дублирование информации, поскольку как адрес уровня 3, так и информационный элемент «тип сообщения» указывают, ориентировано ли сообщение на порт или оно является сообщением общего управления.

Непосредственно за общим заголовком сообщения протокола управления следует обязательный информационный элемент, идентифицирующий конкретную функцию, с которой связано инициирующее или подтверждающее сообщение. Этим информационным элементом в сообщениях PORT_CONTROL и PORT_CONTROL_ACK является «Элемент функции управления» (Controlfunction-element) .

Сообщения PORT_CONTROL поддерживают блокировку и разблокировку всех портов ТфОП, ISDN и арендованных линий, а также ряд функций, специфических для портов ISDN: активизацию и деактивизацию, индикацию ошибок и рабочих характеристик, управление потоком сигнализации. В связи с этим в сообщения могут вводиться соответствующие необязательные информационные элементы. Например, сообщения PORT_CONTROL: performance-grading содержат информационный элемент «Качество работы».

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

Сеть доступа не всегда осведомлена о том, занят или нет пользовательский порт, поскольку сигнализация ISDN ею не интерпретируется и поскольку некоторые порты ISDN могут быть активными, даже когда отсутствует сигнализация или нагрузка. Исчерпывающие сведения о состоянии портов имеются только на АТС. Поэтому в том случае, когда инициатором блокировки порта является сеть доступа, она запрашивает об этом АТС, передавая свой запрос в сообщении AN/PORT_CONTROL: block-request. АТС может ответить сообщением LE/PORT_CONTROL: block, указывающим, что она заблокировала порт, либо немедленно, либо сразу же после освобождения порта. Сеть доступа может затем передать свое сообщение AN/PORT_CONTROL: block без опасности нарушить обслуживание вызовов портом. Если АТС не отвечает на сообщение AN/PORT__CONTROL: block-request в течение некоторого времени, сеть доступа может передать сообщение AN/ PORT_CONTROL: block с риском нарушить текущие связи пользователей.

АТС не должна передавать запрос блокировки в сеть доступа, поскольку она может блокировать порт без нарушения текущих связей, т.к. она знает об их состоянии. Инициируя блокировку порта, АТС сразу передает сообщение PORT_CONTROL: block.

Чтобы разблокировать ранее заблокированный порт, обе стороны должны передать и принять сообщение PORT__CONTROL:

unblock. Разблокировка отменяется, если с любой стороны передается сообщение PORT_CONTROL: block или если сеть доступа передает сообщение AN/PORT-CONTROL: block-request после приема сообщения PORT_CONTROL: unblock.

Автор вынужден отметить, что описанные процедуры блокировки и разблокировки портов протоколов V5 не соответствуют рекомендации ITU-TX.731 относительно управления состояниями, что создает некоторые проблемы при использовании методов сети эксплуатационного управления системами связи TMN. Для согласования Х.731 с интерфейсом V5 разработан специальный «мэппинг», что несколько увеличивает сложность интерфейсов управления.

- Сообщения COMMON_CONTROL и COMMON_CONTРОL_АСКтоже содержат обязательный информационный элемент «Идентификатор-функции-управления» (control-function-ID). Некоторые сообщения общего управления, связанные с изменением конфигурации интерфейса, содержат информационный элемент «Вариант», в котором указывается номер предлагаемого варианта конфигурации. Сообщения COMMON_CONTROL: notready-for-reprovisioning (не-готов-к-реконфигурации) и COMMON_CONTROL: cannot-reprovision (реконфигурация-невозможна) содержат также информационный элемент Rejectioncause (Причина-отказа). Сообщения COMMON_CONTROL: variant-and-interface-ID (вариант-и-идентификатор-интерфейса) содержат информационный элемент «Идентификатор интерфейса».

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

В главах 3 и 4 подробно отмечалось, что каждый пользователь базового доступа ISDN имеет свой D-канал сигнализации 16 Кбит/с. Это может привести к ситуациям, когда большое количество пользовательских портов пытаются использовать один и тот же сигнальный канал 64 Кбит/с в интерфейсе V5.

Чтобы предотвратить перегрузку С-канала, содержащего С-пути типа Ds, нужно, чтобы станция могла запросить в сети доступа блокировку сигналов по D-каналу определенного пользовательского порта ISDN. С этой целью АТС передает сообщение LE/ PORT_CONTROL: D-channel-block (блокировка-D-канала), а после окончания ситуации перегрузки — сообщение LE/PORT_CONTROL: D-channel-unblock (разблокировка-D-канала).

Для активизации и деактивизации портов базового доступа ISDN предусматриваются следующие сообщения. Если активизация происходит по инициативе пользователя, на станцию передается сообщение AN/PORT_CONTROL: activation-initiated-by-user (активизация-по-инициативе-пользователя). Как правило, АТС отвечает сообщением LE/PORT_CONTROL: activate-access (активизировать-доступ), которое инициирует передачу соответствующего сигнала от сети к пользователю. Пользователь получает и тактовый синхросигнал, после чего к АТС передается сообщение AN/PORT_CONTROL: access-activated (доступ-активизирован). Если активизация осуществляется по инициативе АТС, то от нее передается сообщение LE/PORT_CONTROL: activate-access.

Деактивизацию АТС запрашивает с помощью сообщения LE/PORT_CONTROL: deactivate-access (деактивизировать-доступ). После деактивизации доступа к АТС передается сообщение AN/PORT_CONTROL: access-deactivated (доступ-деактивирован).

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

Повышенное внимание, уделяемое в этой книге протоколу ТфОП, вызывает необходимость дополнительных пояснений к двум последним функциям управления. В ряде случаев может понадобиться принудительно возвратить протокол ТфОП в исходное состояние. Для самого протокола ТфОП это более сложная проблема, чем для других протоколов V5, поскольку сообщения протокола ТфОП отображаются на сигналы конкретных пользовательских портов, которые не предусматривают общего рестарта самого протокола. Если любая сторона интерфейса V5 инициирует рестарт протокола ТфОП, она выдает сообщение COMMON__CONTROL: restart. Принимающая сторона должна подтвердить его прием передачей в обратном направлении сообщения СОМMON_CONTROL: restart-acknowledge. Оба этих сообщения, СОМMON_CONTROL: restart и COMMON_CONTROL: restart-acknowledge, являются управляющими сообщениями, поэтому подтверждаются, соответственно, сообщениями COMMON_CONTROL_ACK: