КАТЕГОРИИ:
АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
|
ПРОТОКОЛ УПРАВЛЕНИЯ ТРАКТАМИ ИНТЕРФЕЙСА V5.2 ⇐ ПредыдущаяСтр 2 из 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: Deferred-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 последовательно нумеруются с использованием информационного элемента «Порядковый-номер». Подобно сообщениям отказа в переключении, они должны указывать на происхождение проблемы, но, в отличие от сообщений отказа в переключении, не должны идентифицировать канальный интервал.
|