8.1. Протокол назначения несущих каналов
8.1. Протокол назначения несущих каналов
Выбранная в качестве эпиграфа строчка итальянского поэта Филиппе Пананти полностью отражает суть протокола назначения несущих каналов (ВСС — Bearer Channel Connection protocol). Возможности этого протокола определяют основные концептуальные преимущества интерфейса V5.2 и позволяют революционизировать структуру современного узла коммутации. Именно благодаря протоколу ВСС можно резко уменьшить физические размеры абонентского оборудования АТС за счет его замены несколькими интерфейсами V5.2, что в значительной степени преобразует и всю телекоммуникационную сеть, состоящую из небольшого числа таких узлов.
Следует отметить принципиальное различие между интерфейсами V5.1 и V5.2. Несущие каналы интерфейса V5.1 жестко закреплены за цифровыми каналами пользовательских трактов, то есть между каждым используемым несущим каналом интерфейса и соответствующим каналом пользовательского порта существует постоянное соединение. С интерфейсом V5.2 дело обстоит иначе. Жесткое закрепление несущих каналов этого интерфейса за каналами пользовательских портов отсутствует; более того, количество используемых несущих каналов в интерфейсе всегда значительно меньше количества обслуживаемых им каналов пользовательских портов. Несущий канал интерфейса V5.2 предоставляется только тому каналу пользовательского порта, для которого запрашивается услуга связи, и только на время пользования этой услугой. Таким образом, соединение любого несущего канала интерфейса с каналом пользовательского порта является оперативно коммутируемым.
В дальнейшем, для краткости, такие оперативно коммутируемые соединения мы будем, как правило, называть В-соединениями, поскольку точный перевод на русский язык их английского названия bearer channel connections получается слишком многословным.
Переводя строчку эпиграфа с поэтического на технический язык, следует определить функции сообщений протокола ВСС как управление В-соединениями, то есть соединениями между цифровыми каналами портов пользователей и несущими канальными интервалами в трактах интерфейса V5.2. Эти сообщения назначают несущие канальные интервалы интерфейса для каналов портов пользователей, когда это требуется, и отменяют такие назначения, когда услуга больше не нужна, что дает возможность интерфейсу V5.2 концентрировать нагрузку. Концентрация обеспечивается специальным механизмом динамического распределения канальных интервалов, которым управляет АТС. Последнее связано с тем, что сеть доступа не всегда осведомлена о том, каким пользовательским портам в данный момент требуются канальные интервалы, поскольку она не интерпретирует сигнализацию управления соединениями пользователей.
В контексте протокола ВСС существует три типа В-соединений'
1) соединения в АТС и в интерфейсе V5.2, создаваемые оперативно для обслуживания каждого вызова ТфОП и ISDN с концентрацией трафика на стороне сети доступа;
2) соединения, создаваемые в АТС оперативно для каждого вызова, но использующие постоянные соединения в сети доступа, закрепленные в интерфейсе V5.2 за линиями ТфОП и ISDN с высокой нагрузкой (например, линиями УАТС) и за такими линиями, блокировка которых в сети доступа или в интерфейсе V5.2 недопустима (например, линиями охранной сигнализации),
3) полупостоянные соединения, устанавливаемые в сети доступа и АТС для поддержки услуг полупостоянных арендованных линий.
Для В-соединений первого типа процедура ВСС проводится в начале и в конце обслуживания каждого вызова, а управление соединением пользователя осуществляется со стороны АТС. Для В-соединений второго и третьего типов процедуры протокола ВСС проводятся под контролем системы эксплуатационного управления АТС (через интерфейс Qма), которая не назначает для линий конкретных канальных интервалов и трактов интерфейса V5, но должна иметь об этом информацию.
Интерфейс V5 2 обеспечивает возможность создания и нарушения многоканальных В-соединений «n x 64 Кбит/с», где n может принимать значения от 1 до 30, для поддержки коммутируемых связей Н0, Н11 и будущих высокоскоростных услуг. Такие В-соединения могут быть всех трех типов Каналы DSS-1 типа Н0 и Н 11 не должны быть «видимы» для интерфейса V5.2, но должны поддерживаться в нем прозрачно как n соединений каналов 64 Кбит/с. Соединения мультимедиа также не должны быть «видимы» для интерфейса V5.2, но должны поддерживаться прозрачно как несколько независимых соединений.
Протокол ВСС поддерживает только соединения между пользовательскими портами сети доступа и канальными интервалами интерфейса V5.2. Соединения «пользовательский порт - пользовательский порт» протоколом не поддерживаются, что, однако, не исключает возможности установления таких соединений полностью под управлением сети доступа, например, при отказе интерфейса V5.2.
В дополнение к назначению и отмене назначения несущих канальных интервалов протокол ВСС, в частности, позволяет АТС проверять правильность назначения, а сети доступа - информировать АТС о неисправностях, которые могут повлиять на назначение несущих канальных интервалов. Все это (а в первую очередь - сам механизм динамического назначения несущих каналов) существенно повышает надежность интерфейса V5.2, т.к. позволяет при обслуживании портов пользователей обходить те тракты интерфейса, которые имеют повреждения, и использовать только канальные интервалы исправных трактов интерфейса V5.2. Напомним, что V5.2 поддерживает до 16 трактов 2048 Кбит/с.
Структура сообщения протокола ВСС приведена на рис. 8.1. Все сообщения ВСС содержат в байтах 2 и 3 ссылочный номер процесса ВСС, к которому они относятся. В дополнение к ссылочному номеру там же размещен специальный S-бит, указывающий, был ли процесс инициирован сетью доступа или опорной АТС. В принципе, одно и то же значение ссылочного номера может использоваться процессом, инициированным станцией, и процессом, инициированным сетью доступа, и, хотя такая ситуация маловероятна, S-бит исключает возможность путаницы.
Протокол ВСС трактует каждое назначение и каждую отмену назначения несущего канала V5.2 как отдельный процесс, идентифицируемый собственным ссылочным номером. Каждый такой процесс завершается успешным назначением, успешной отменой назначения или прерыванием. Разные процессы создаются и завершаются параллельно, так что назначение или отмена назначения одного несущего канального интервала не задерживает другие назначения и отмены назначения.
Рис. 8.1. Формат ссобщения протокола ВСС
Типы сообщений протокола ВСС представлены в таблице 8.1. Что же касается направления передачи сообщений, то для протокола ВСС ведущей, как правило, является сторона АТС, а ведомой — сторона сети доступа, так как сеть доступа не осуществляет управления соединениями пользователей. Исключением из этого правила являются процессы, связанные с сообщениями AN_FAULT и PROTOCOL_ERROR, которые всегда инициируются со стороны сети доступа.
Сторона АТС запрашивает назначение канального интервала V5.2 посылкой в сторону сети доступа сообщения ALLOCATION. Это сообщение содержит ссылочный номер активизированного им процесса ВСС, используемый в дальнейших сообщениях, которые сопутствуют данному назначению. Сообщение также содержит в обязательном информационном элементе «Идентификация порта пользователя» адрес пользовательского порта.
Для портов ТфОП этот информационный элемент одновременно идентифицирует и канал порта, так как порт содержит всего один канал.
Для портов ISDN, содержащих каждый более одного В-канала, используется информационный элемент «Идентификация канала порта ISDN». Номер канала пользовательского порта ISDN в этом информационном элементе помещается в поле из 5 битов. В случае первичного доступа ISDN каналы от В1 до В31 будут иметь номера от 1 (00001) до 31 (11111). В случае базового доступа канал В1 будет иметь номер 1 (00001), а канал В2 - номер 2 (00010).
Несущий канал интерфейса, назначаемый для канала ТфОП или для В-канала порта ISDN, идентифицируется информационным элементом «Идентификация канального интервала V5», указывающим как тракт интерфейса V5.2, так и канальный интервал в этом тракте. Этот информационный элемент также содержит указания на то, можно ли пренебречь каким-либо существующим В-соединением ради данного В-соединения как имеющего более высокий приоритет.
Структура сообщения ALLOCATION приведена в таблице 8.2. Напомним, что в этой и в следующих таблицах информационный элемент может быть обязательным - М (Mandatory) и необязательным О (Option).
Информационный элемент «Идентификатор канала пользовательского порта ISDN» используется, когда необходимо назначить один канальный интервал для одного В-канала порта ISDN, и идентифицирует этот В-канал. Информационный элемент «Идентификатор канального интервала V5» определяет канальный интервал, назначенный в интерфейсе для указанного В-канала.
Информационный элемент «Таблица соответствия» длиной 11 байтов (рис. 8.2) используется для идентификации блока канальных интервалов V5.2 тогда, когда необходимо назначить несколько канальных интервалов для поддержки высокоскоростных (n x 64 кбит/с) услуг ISDN (а также когда нужно отметить это назначение). Все назначенные канальные интервалы должны содержаться в одном тракте 2048 Кбит/с.
Рис. 8.2. Информационный элемент "Таблица соответствия"
Этот же информационный элемент идентифицирует канальные интервалы в интерфейсе ISDN пользователь/сеть, для которых должны быть назначены канальные интервалы V5.2 (или должно быть отменено их назначение). Соответствие между канальными интервалами V5 и В-каналом пользовательского порта осуществляется по принципу «один к одному» в том же порядке, в котором они отмечаются в таблице соответствия. Когда несколько канальных интервалов назначаются как один блок, процедура отмены назначения, о которой будет сказано дальше в этом параграфе, может быть применена либо ко всему блоку, либо к отдельным канальным интервалам.
Поле «идентификатор тракта» определяет тот тракт в интерфейсе, канальные интервалы которого назначаются таблицей соответствия. Максимальное значение идентификатора 256. Байты с 4 по 7 идентифицируют канальные интервалы V5.2, которые рассматриваются как один блок. Если канальный интервал используется в процессе назначения (отмены назначения), то соответствующий ему бит в поле байтов с 4 по 7 имеет значение 1, в противном случае - 0. Байты с 8 по 11 определяют каналы пользовательского порта ISDN (с базовым или первичным доступом), для которых назначаются отмеченные в байтах с 4 по 7 канальные интервалы V5.2. Если для канала порта назначается канальный интервал, то соответствующий этому каналу бит в поле байтов с 8 по 11 имеет значение 1, в противном случае - 0.
Сообщение о выполнении назначения используется стороной сети доступа для передачи стороне АТС информации о том, что назначение несущих каналов интерфейса V5.2 для каналов пользовательского порта успешно завершено (таблица 8.3).
Если сторона сети доступа не может подчиниться сообщению ALLOCATION, посланному стороной АТС, она отвечает сообщением ALLOCATION_REJECT с информационным элементом «Причина отказа». Этот информационный элемент содержит поле, указывающее причину (таблица 8.4), и в некоторых случаях - поле диагностики. Назначение может оказаться невозможным из-за неисправностей или блокировки внутри сети доступа, в порту пользователя или в интерфейсе V5. В назначении также может быть отказано из-за существующих В-соединений или даже без указания определенной причины. Диагностические поля содержат информацию, которая может помочь более точно выяснить причину отказа.
Сообщения, связанные с отменой назначения, имеют форматы и информационные элементы, идентичные тем, которые используются в сообщениях, связанных с назначением, поскольку в обоих случаях требуется равноценная информация. Обычно сообщение DEALLOCATION отменяет назначение, чтобы нарушить В-соединение после завершения той связи, для поддержки которой оно создавалось, но сторона АТС может также послать сообщение DEALLOCATION, чтобы прервать процесс назначения. Структура сообщения DEALLOCATION показана в таблице 8.5. Информационный элемент «Идентификатор канала пользовательского порта ISDN» используется при отмене назначения несущего канального интервала интерфейса V5.2 для В-канала порта ISDN и определяет номер этого В-канала. Информационный элемент «Таблица соответствия» определяет блок несущих канальных интервалов интерфейса V5.2 и блок В-каналов ISDN, для которых они были назначены, с целью отменить это назначение.
Об успешной отмене назначения сторона сети доступа информирует сторону АТС посылкой сообщения DEALLOCATION_COMPLETE. Это сообщение посылается, даже если В-соединения не существует, поскольку в данном случае отмена назначения позволяет подтвердить нарушение В-соединения, например, при логическом сбое. Запрос отмены назначения может получить отказ в виде сообщения DEALLOCATION_REJECT, содержащего информационный элемент «Причина отказа» длиной от 3 до 14 байтов, который может включать в себя дополнительные параметры, не используемые при отказе в назначении.
Сообщение AUDIT (таблица 8.6) дает возможность стороне АТС запросить от сети доступа недостающую информацию о В-соединении, для идентификации которого сторона АТС использует те данные, которые у нее имеются. Это могут быть либо данные, идентифицирующие канал пользовательского порта, либо данные, идентифицирующие несущий канальный интервал интерфейса V5.2. Таким образом, сторона АТС идентифицирует какой-то один конец В-соединения и ожидает со стороны сети доступа ответ, содержащий идентификацию другого его конца.
Сторона сети доступа посылает в ответ сообщение ALJDIT_COMPLETE (структура которого идентична структуре сообщения AUDIT), либо содержащее полную информацию о В-соединении, либо указывающее на то, что такого В-соединения не существует. В последнем случае сообщение AUDIT_COMPLETE содержит необязательный информационный элемент «Незавершенное соединение» (расположенный за байтом «Идентификатор канального интервала V5»), в котором имеется поле, указывающее причину неуспеха, что может помочь в устранении логического сбоя.
Процессы обработки неисправностей и ошибок являются единственными процессами ВСС, инициируемыми сетью доступа. Эти процессы используются для передачи в сторону АТС сигналов, оповещающих о неисправности в сети доступа или об ошибках в протоколе ВСС, выявленных сетью доступа.
При нарушении активного В-соединения из-за неисправности, возникшей в сети доступа, сторона сети доступа передает в сторону АТС сообщение AN_FAULT. Формат сообщения ANJFAULT аналогичен формату сообщений ALLOCATION или DEALLOCATION для одиночного несущего канала, за исключением того, что информационные элементы идентификации порта пользователя (и В-канала для портов ISDN) и несущего канала V5.2 включаются в это сообщение только тогда, когда они известны. Сообщение AN_FAULT подтверждается сообщением AN_FAULT_ACKNOWLEGE, имеющим тот же ссылочный номер, что и сообщение, которое оно подтверждает.
Если сеть доступа обнаруживает ошибку в протоколе ВСС, она посылает в сторону АТС сообщение PROTOCOL_ERROR (таблица 8.7.). В этом сообщении содержится обязательный информационный элемент «Причина ошибки протокола», определяющий тип ошибки протокола и, где это возможно, тип сообщения, в котором ошибка была выявлена.
Причинами ошибок протокола могут быть ошибка дискриминатора протокола, неопознанное сообщение, информационный элемент с нарушением порядка следования, повторение необязательного или пропуск обязательного информационного элемента, ошибка в содержании информационного элемента, неопознанный информационный элемент, несовместимость сообщения с состоянием протокола ВСС, повторение обязательного информационного элемента и наличие в сообщении слишком большого числа информационных элементов.
Более детальная информация о протоколе ВСС и его процедурах содержится в приложении Е стандарта ETS 300 347-1.
8.2. Протокол управления трактами интерфейса V5.2
Как уже отмечалось выше, интерфейс V5.2 содержит несколько (до 16) цифровых трактов 2048 Кбит/с. Такое отличие от интерфейса V5.1 требует дополнительных функций управления этими трактами, включая проверку соответствия двух сторон интерфейса, соединенных физическим трактом или трактами. Последнее достигается присвоением каждому тракту на каждой стороне интерфейса отличительного ярлыка, что позволяет, в частности, правильно подсоединить вновь несколько физических трактов, если они были отсоединены из-за неисправности, или при проведении планового техобслуживания. Для этого предусматривается специальный механизм проверки ярлыков трактов.
В дополнение к проверке ярлыков и целостности самих трактов, должна обеспечиваться возможность перевода трактов в состояния «рабочее» и «нерабочее».
Последнее действие аналогично блокировке и разблокировке портов в сети доступа с двумя отличиями: необходимостью защитить сигнализацию интерфейса V5.2 и необходимостью минимизировать нарушения в обслуживании трафика. Эти отличия приводят к тому, что если инициатива блокировки тракта исходит от сети доступа, последняя должна иметь возможность согласовать эти вопросы с АТС, так как именно АТС отвечает за обслуживание и обладает подробной информацией о проходящей нагрузке. Запрашивая разрешение заблокировать тракт, сеть доступа указывает, допустима ли отсрочка в исполнении этого запроса. Блокировка тракта с отсрочкой позволяет дождаться завершения всех уже установленных к моменту запроса соединений пользователей, а блокировка без отсрочки выполняется немедленно.
Структура сообщения протокола управления трактами интерфейса V5 представлена на рис. 8.3. Информационный элемент «Тип сообщения» в заголовке определяет сообщение как управляющее - LINK_CONTROL или как подтверждающее - LINK_CONTROL_ACK. Строго говоря, сообщения второго типа LINK_CONTROL_ACK не являются, по мнению автора, необходимыми (даже при разблокировке тракта, о чем будет сказано в конце этого параграфа), поскольку эту функцию выполняет уровень 2 протокола.
В сообщениях протокола управления трактами интерфейса V5.2 имеется единственный специализированный обязательный информационный элемент «Функция управления трактом» (Linkcontrol-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-identificationrelease. Получив такое сообщение, другая сторона удаляет маркировку. Удаляется маркировка присвоением биту 7 нулевого канального интервала значения 1.
Сеть доступа может запросить у станции блокировку тракта путем передачи сообщения LINK__CONTROL: Deferred-link-blocking-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, но это не рекомендуется, т.к. безопаснее дать АТС некое предупреждение о намерении, прежде чем указывать, что тракт недоступен.
АТС не должна запрашивать блокировку тракта у сети доступа, поскольку станции известно, происходит ли обслуживание вызовов, и она может управлять использованием канальных интервалов интерфейса V5. Если АТС принимает решение заблокировать тракт, она может использовать рассматриваемый в следующем параграфе протокол защиты для переключения С-каналов на канальные интервалы другого тракта, а также может использовать рассмотренный в предыдущем параграфе протокол назначения несущих каналов ВСС, чтобы гарантировать, что никакие пользовательские порты не используют несущие канальные интервалы тракта, который предполагается заблокировать. После завершения всех текущих связей пользователей АТС может передать сообщение LINK_CONTROL: Link-block, информирующее сеть доступа о том, что тракт заблокирован.
При разблокировке ранее заблокированного тракта применяется процедура координированной разблокировки, поскольку сеть доступа и АТС автономны и могут независимо выполнять функции техобслуживания, а протоколы V5 не дают возможность одной стороне информировать об этом другую. Когда одна из сторон предполагает разблокировать тракт, она передает другой стороне сообщение LINK_CON7 ROL: Link-unblock. Если другая сторона согласна разблокировать тракт, она отвечает таким же сообщением LINK_CONTROL: Link-unblock.
8.3. Протокол защиты V5.2
В первый раз в этой книге протокол защиты был упомянут в четвертой строке таблицы 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 последовательно нумеруются с использованием информационного элемента «Порядковый-номер». Подобно сообщениям отказа в переключении, они должны указывать на происхождение проблемы, но, в отличие от сообщений отказа в переключении, не должны идентифицировать канальный интервал.
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:
restart и COMMON_CONTROL_ACK: restart-acknowledge. Такая избыточность подтверждений (на уровне 2 плюс двойное квитирование на уровне 3) обуславливается тем, что сброс протокола ТфОП может повлиять на обслуживание нескольких тысяч пользователей. Внимательный читатель, вероятно, заметил противоречия между этим подходом и техническими решениями протокола защиты, рассмотренного в предыдущем параграфе. Функция рестарта протокола ТфОП включена в протокол управления, хотя ее можно было бы включить в протокол ТфОП точно таким же образом, как функция рестарта протокола защиты непосредственно встроена в этот протокол. Естественным также могло бы быть использование сообщения PROTOCOL_ERROR протокола защиты и для других протоколов [83] либо путем введения его в каждый из этих протоколов, либо включением соответствующих функций общего управления в протокол управления. Логичным было бы использовать в обоих случаях одинаковый подход, но идеальных протоколов, как известно, не бывает.