ПРОТОКОЛ УПРАВЛЕНИЯ ТРАКТАМИ ИНТЕРФЕЙСА V5.2

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

В дополнение к проверке ярлыков и целостности самих трак­тов, должна обеспечиваться возможность перевода трактов в со­стояния «рабочее» и «нерабочее».

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

Структура сообщения протокола управления трактами интер­фейса V5 представлена на рис. 8.3. Информационный элемент «Тип сообщения» в заголовке определяет сообщение как управляющее — LINK_CONTROL или как подтверждающее - LINK_CONT-ROL_ACK. Строго говоря, сообщения второго типа LINK_CONT-ROL_ACK не являются, необходимыми даже при разблокировке тракта поскольку эту функцию выполняет уровень 2 протокола.

Рис. 8.3. Структура сообщения протокола управления трактами

В сообщениях протокола управления трактами интерфейса V5.2 имеется единственный специализированный обязательный информационный элемент «Функция управления трактом» (Link-control-function).

Операцию идентификации тракта может инициировать лю­бая сторона интерфейса с помощью передачи сообщения LINK_ CONTROL: Link-identification-request (запрос-идентификации-тракта). Если сигнал маркировки принимается стороной, запро­сившей идентификацию, по тракту с ярлыком, который соответ­ствует ярлыку передающей стороны, маркировка считается верной, тракт идентифицирован, его целостность проверена. Так как за­просить идентификацию может любая сторона интерфейса, воз­можны конфликтные ситуации при передаче одного и того же сиг­нала более чем по одному тракту одновременно. В идеале, для раз­ных интерфейсов следовало бы применять разные сигналы мар­кировки во избежание путаницы при одновременном тестирова­нии нескольких интерфейсов, но в интерфейсе V5.2 это не реали­зовано, поскольку вероятность случайного возвращения сигнала маркировки по исправному тракту другого интерфейса незначи­тельна.

Сторона, которая принимает запрос идентификации, может отказать в удовлетворении запроса. Это может произойти, если, например, продолжается обработка предыдущего запроса иденти­фикации тракта, поскольку спецификации интерфейса V5 не предусматривают идентификацию более одного тракта одновремен­но. Отказ удовлетворить запрос производится путем передачи со­общения LINK_CONTROL: Link-identification-rejection (отказ-в-идентификации-тракта). Сценарий идентификации тракта пред­ставлен на рис. 8.4.

Если запрос принимается приемной стороной для выполне­ния, то она маркирует указанный тракт и отвечает сообщением LINK_CONTROL: Link-identification-acknowledgement, подтвер­ждающим выполнение запроса. Маркировка тракта производится присвоением значения 0 биту 7 в нулевом канальном интервале этого тракта.

Когда сторона, давшая запрос, получила подтверждение и проверила маркировку, она может запросить удаление маркиров­ки с помощью сообщения LINK_CONTROL: Link-identification-release. Получив такое сообщение, другая сторона удаляет марки­ровку. Удаляется маркировка присвоением биту 7 нулевого каналь­ного интервала значения 1.

Рис. 8.4. Сценарий обмена сообщениями идентификации тракта

Сеть доступа может запросить у станции блокировку тракта путем передачи сообщения LINK_CONTROL: Deferred-link-block-ing-request (запрос-блокировки-тракта-с-отсрочкой) или сообщения LINK_CONTROL: Non-deferred-link-blocking-request (запрос-блоки-ровки-тракта-без-отсрочки). Сообщение LINK_CONTROL: De­ferred-link-blocking-request менее срочное, оно указывает, что сеть доступа готова ждать, пока АТС переключит С-каналы на другой тракт и пока завершатся текущие связи пользователей. Сообщение LINK_CONTROL: Non-deferred-link-blocking-request более срочное, оно указывает, что сеть доступа не может ждать, пока завершатся текущие связи и пока станция переключит С-каналы на другой тракт (рис. 8.5). Если в тракте нет С-каналов, вместо сообщения LINK_CONTROL: Non-deferred-link-blocking-request можно исполь­зовать сообщение LINK_CONTROL: Link-block, но это не рекомен­дуется, т.к. безопаснее дать АТС некое предупреждение о намере­нии, прежде чем указывать, что тракт недоступен.

Рис. 8.5. Сценарий запроса блокировки тракта

АТС не должна запрашивать блокировку тракта у сети досту­па, поскольку станции известно, происходит ли обслуживание вы­зовов, и она может управлять использованием канальных интерва­лов интерфейса V5. Если АТС принимает решение заблокировать тракт, она может использовать рассматриваемый в следующем па­раграфе протокол защиты для переключения С-каналов на каналь­ные интервалы другого тракта, а также может использовать рассмот­ренный в предыдущем параграфе протокол назначения несущих каналов ВСС, чтобы гарантировать, что никакие пользовательские порты не используют несущие канальные интервалы тракта, кото­рый предполагается заблокировать. После завершения всех текущих связей пользователей АТС может передать сообщение LIN K_CONT-ROL: Link-block, информирующее сеть доступ а о том, что тракт за­блокирован.

При разблокировке ранее заблокированного тракта приме­няется процедура координированной разблокировки, поскольку сеть доступа и АТС автономны и могут независимо выполнять функции техобслуживания, а протоколы V5 не дают возможность одной стороне информировать об этом другую. Когда одна из сто­рон предполагает разблокировать тракт, она передает другой сто­роне сообщение LTNK_CONTROL: Link-unblock. Если другая сто­рона согласна разблокировать тракт, она отвечает таким же сооб­щением LINK_CONTROL: Link-unblock.

8.3.ПРОТОКОЛ ЗАЩИТЫ V5.2

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

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

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

Рис. 8.6. Структура сообщения протокола защиты

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

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

Таблица 8.8. Список сообщений протокола защиты

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

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

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

Рис. 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, подтверждающим, что соответствующие счет­чики установлены в «О». Напомним, что нумеруются сообщения переключения и ошибок в протоколе, т.е. первые шесть из восьми сообщений протокола защиты.

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

Таблица 8.9. Кодирование типа ошибки протокола

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