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