В первый раз в этой книге протокол защиты был упомянут в четвертой строке таблицы 6.2 главы 6 как одно из основных отличий интерфейса V5.2 от V5.1. Собственно говоря, суть протокола защиты (как отличительной особенности интерфейса V5.2) сформулирована гораздо раньше в другой Книге: «Двоим лучше, нежели одному; потому что у них есть доброе вознаграждение в труде их: ибо если упадет один, то другой поднимет товарища своего. Но горе одному, когда упадет, а другого нет, который поднял бы его... И если станет преодолевать кто-либо одного, то двое устоят против него: и нитка, втрое скрученная, нескоро порвется» (Екклесиаст, гл. 4, ст. 9-12). Протокол защиты охраняет логические С-каналы от отказа одного тракта в интерфейсе V5.2, обеспечивая возможность другим протоколам продолжать работу, несмотря на появление неисправностей в оборудовании.

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

Основным событием, вызывающим необходимость защиты, является отказ тракта 2048 Кбит/с. Протокол защиты используется также в случае устойчивых отказов в звеньях уровня 2 протокола V5 (т.е. устойчивый отказ одного из звеньев, используемых протоколами ВСС, управления, управления трактами, ТфОП или самим протоколом защиты). Кроме того, необходим постоянный контроль флагов всех активных и резервных С-каналов, чтобы обеспечить защиту от отказов, которые не обнаруживаются механизмами уровня 1. Так, если в физическом С-канале в течение 1 с не принимается комбинация флага, то этот С-канал должен рассматриваться как нерабочий. Если обнаруживается отказ резервного С-канала, то защитное переключение на него не должно производиться.

Механизм защиты применяется также и по отношению к С-пути самого протокола защиты. В отличие от любых других протоколов 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 последовательно нумеруются с использованием информационного элемента «Порядковый-номер». Подобно сообщениям отказа в переключении, они должны указывать на происхождение проблемы, но, в отличие от сообщений отказа в переключении, не должны идентифицировать канальный интервал.