7.2. Информационные элементы сообщений протокола ТфОП
7.4. Протокол ТфОП на стороне сети доступа
7.1. Проблема ТфОП
Плодотворная дебютная идея интерфейса V5 с самого начала была обращена лицом в будущее. Действительно, что может быть перспективнее идеи собрать рассмотренные в предыдущей главе три источника (речь, данные и видео) и три составные части (металлический кабель, оптоволокно и радиоканал), охватывающие все многообразие задач и средств сети доступа, в единый интерфейс, являющийся своего рода шлюзом к не менее многообразной сети узлов коммутации. Тем более, что, как видно из материалов предыдущей главы, спецификации V5 неплохо справляются с абонентской сигнализацией ISDN и являются действительно открытыми для новых протоколов, создаваемых различными АВСфорумами и консорциумами. Беда пришла, откуда не ждали - от телефонной сети общего пользования (ТфОП). Проспавшая почти 100 лет сигнализация по аналоговым абонентским линиям ТфОП, как красавица из сказки, сохранив за время сна свою актуальность, оказалась, тем не менее, весьма капризным объектом, обремененным множеством устаревших предрассудков. Возможно, то же произошло и со Спящей Красавицей, но история об этом умалчивает, ибо, согласно литературному закону К. Симонова, «Все романы на свадьбах кончают недаром, потому что не знают, что делать с героем потом». Что же касается протокола ТфОП для интерфейса V5, то выступившая в роли сказочного принца международная рабочая группа по V5 столкнулась, против ожиданий, со множеством серьезных трудностей. Речь идет о принципиальной несовместимости различных исторически сложившихся национальных подходов к обработке вызовов ТфОП, о невозможности отобразить все национальные особенности управления соединениями ТфОП на управлении соединениями ISDN (как предполагалось вначале), о компромиссах при адаптации спецификаций протокола V5 к национальным требованиям и т.п.
Помимо этого, важная особенность протокола ТфОП связана с тем, что сообщения уровня 3 для управления соединениями ТфОП вырабатываются и принимаются в самой сети доступа. Сообщения ISDN, как было показано в предыдущей главе, могут транслироваться кадрами от АТС в пользовательский порт и в обратном направлении без их интерпретации сетью доступа. Порты же ТфОП не обрабатывают сообщения уровня 3, и, следовательно, конвертировать эти сообщения в сигналы пользовательского порта и обратно должна сеть доступа.
Тем не менее, с целью сохранения для протокола ТфОП того же принципа прозрачности, который используется для сигнализации ISDN, сделано так, что сигналы, генерируемые терминалом ТфОП (т.е. шлейф замкнут, шлейф разомкнут), отображаются непосредственно на сообщения протокола ТфОП, а для идентификации порта ТфОП, от которого поступают сигналы, в эти сообщения вводится адрес уровня 3. Затем сообщения передаются на станцию через интерфейс V5. В сообщениях, принимаемых от станции, также имеется адрес уровня 3, используемый для идентификации пользовательского порта, куда адресовано сообщение. Принятое сообщение преобразуется в соответствующий сигнал (посылка вызова, переполюсовка и т.п.), который подается в идентифицированный этим адресом порт ТФОП.
Главная функция протокола ТфОП - поддержка национального протокола управления созданием и нарушением соединений ТфОП. С этой целью для каждого вызова абонента ТфОП (как исходящего, так и входящего) протокол ТфОП предусматривает создание в интерфейсе V5 логического соединения, использующего ресурс того С-пути в интерфейсе V5, который предназначен для сигнализации ТфОП, и называемого сигнальным путем (signalling path). Кроме того, протокол ТфОП может использовать этот же С-путь и без создания в нем сигнального пути, когда возникает необходимость в передаче информации, не связанной с управлением соединениями ТфОП (например, для передачи со стороны сети доступа к стороне АТС данных о линии пользователя). Сигнальный путь существует в течение всех фаз соединения ТфОП и обеспечивает прозрачный обмен сообщениями уровня 3 между логическими объектами протокола ТфОП, расположенными по разные стороны интерфейса.
Следует подчеркнуть, что при отсутствии сети доступа, т.е. при непосредственном подсоединении пользовательского порта к телефонной станции, информацией о состоянии абонентской линии и соединения ТфОП полностью владеет АТС. Сообщения нужны в том случае, когда между абонентом и станцией существует сеть доступа, т.к. информация, которая без сети доступа поступает в АТС непосредственно, при наличии сети доступа должна быть передана через эту сеть. Следует подчеркнуть и другое: протокол ТфОП не выполняет функций управления соединениями ТфОП, а лишь обеспечивает перенос сигнальной информации через интерфейс V5. Сама эта информация создается и обрабатывается традиционными участниками соединений ТфОП - АТС и абонентскими терминалами.
7.2. Информационные элементы сообщений протокола ТфОП
Прежде чем перейти к детальному обсуждению сообщений протокола ТфОП, общая структура которых уже приводилась в предыдущей главе, рассмотрим информационные элементы этих сообщений. Для кодирования информационных элементов применяются правила, определенные в ETS 300 102-1, а сами информационные элементы протокола ТфОП и коды их идентификаторов приведены в табл. 7.1.
Четыре первых информационных элемента соответствуют сигналам, передаваемым по абонентской линии ТфОП и/или по аналоговой соединительной линии, используемой для подключения к ТфОП учрежденческой АТС. Остальные информационные элементы используются для управления взаимодействием между сетью доступа и АТС ТфОП и непосредственной связи с сигнализацией по абонентской (или соединительной) линии не имеют.
Структура информационного элемента «Непрерывный-сигнал» показана на рис. 7.1.
Рис. 7.1. Структура информационного элемента "Непрерывный-сигнал"
Данный информационный элемент генерируется либо АТС с целью указать сети доступа, какой непрерывный сигнал следует активизировать в пользовательском порту для передачи его к абонентскому терминалу или к УАТС, либо сетью доступа для передачи в АТС информации о том, какой непрерывный сигнал, принятый от абонентского терминала или УАТС, зафиксировал пользовательский порт. Длина информационного элемента «Непрерывный-сигнал» всегда равна 3 байтам, а кодировка поля «Тип сигнала» соответствует табл. 7.2.
Использование отдельных сообщений о замыканиях и размыканиях шлейфа при передаче импульсов набора номера потребовало бы большого количества сообщений для передачи всего номера. К тому же эти сообщения пришлось бы снабжать указателями времени начала и конца импульсов и пауз, чтобы обеспечить достоверное распознавание цифр номера при приеме. Альтернативным методом является распознавание импульсов и пауз набора номера непосредственно в сети доступа, что позволяет в сообщении V5 указывать сразу определенную цифру. Для этого применяется информационный элемент «Цифра» (Digit-signal), передаваемый, вообще говоря, в обоих направлениях (рис. 7.2), как для обычной передачи номера к АТС, так и для сигналов прямого входящего набора номера (DDI), передаваемых от опорной АТС к малым АТС (специфика включения малых учрежденческих АТС в российскую ТфОП рассматривалась в главе 1 данного тома).
Рис. 7.2. Информационный элемент "Цифра"
Длина информационного элемента «Цифра» всегда равна 3 байтам. В битах 1-4 передается в двоичном коде одна цифра номера, принятая сетью доступа от абонента, или цифра, которую АТС передает в сеть доступа. Нулевое значение всех битов 1-4 соответствует ошибке. Биты 5 и 6 третьего байта всегда имеют значение 0. Поле индикатора запроса подтверждения позволяет АТС запросить сеть доступа указать конец передачи цифры в порт пользователя. В направлении от сети доступа к АТС данный бит всегда имеет значение 0.
Для передачи сигнала посылки вызова используется информационный элемент «Модулированный-вызов» (Cadenced-ringing), предусматривающий возможность задать нужный тип вызывного сигнала. Данный информационный элемент занимает 3 байта и передается только в сообщениях от АТС к сети доступа.
Для передачи в абонентский терминал импульсов тарификации и для некоторых других целей служит информационный элемент «Импульсный-сигнал» (Pulsed-signal), структура которого представлена на рис. 7.3. Длина этого информационного элемента может колебаться от 3 до 5 байтов.
Рис. 7.3. Структура информационного элемента "Импульсный-сигнал"
Данный информационный элемент, передаваемый от АТС к сети доступа или от сети доступа к АТС, указывает на то, что в пользовательском порту ТфОП должен быть сформирован импульсный сигнал, определенный в соответствии с табл. 7.3. Передача этого информационного элемента от сети доступа к АТС говорит о том, что пользовательский порт получил импульсный сигнал от терминала абонента или от УАТС.
Длительность импульсного сигнала должна быть указана в поле «тип длительности импульса». Каждому типу длительности соответствует заранее определенный набор характеристик импульсов и пауз.
Поле «число импульсов» содержит двоичное число, показывающее, сколько импульсов должно быть передано. Нулевое значение в этом поле является ошибочным.
Индикатор подавления (suppression indicator), занимающий биты б и 7 в байте 4, АТС использует, чтобы сообщить сети доступа, должен ли быть подавлен входящий импульсный сигнал. Индикатор запроса подтверждения, размещающийся в битах 6 и 7 байта 4а, необходим АТС, чтобы запросить подтверждение исполнения запроса передачи импульсного сигнала: сигнал начался, сигнал закончился или закончилась одна из серий импульсов. Кодировки этих двух индикаторов представлены в табл. 7.4 и 7.5, соответственно.
В направлении от AN к LE используется информационный элемент «Уведомление-о-передаче», который информирует станцию об исполнении запроса передать импульсный сигнал (Pulsed-signal) или цифру (Digit-signal). Этот элемент уведомляет либо о начале передачи импульса, либо об окончании передачи единственного импульса или одного из импульсов в последовательности импульсов.
Рассмотренные выше четыре информационных элемента, по-видимому, необходимы в любой национальной реализации протокола ТфОП. Кроме них имеются информационные элементы, которые нужны не в каждом случае.
Необходимость передавать на станцию сведения о состоянии линии уже упоминалась. Такого рода сведения могут передаваться в информационном элементе «Данные-о-линии» (Line-information), который связан, в частности, с активизацией и деактивизацией в некоторых УАТС услуги переадресации вызовов путем особой маркировки импенданса линии. Кодировки параметров этого информационного элемента приведены в таблице 7.6. Все не указанные в таблице коды зарезервированы для будущих применений. Ограниченное использование информационного элемента «Данные-о-линии» обусловлено тем, что существуют альтернативные методы управления переадресацией вызовов.
Может потребоваться изменить период времени, в течение которого должен существовать сигнал. Это выполняется с помощью информационного элемента «Время-распознавания» (Recognition-time), используемого, например, когда нужно увеличить время распознавания, чтобы уменьшить вероятность ошибочной интерпретации состояния линии. Длина этого информационного элемента всегда составляет 4 байта, его передача осуществляется только в сообщении от АТС к сети доступа, а структура элемента представлена на рис. 7.4. В поле «сигнал» может помещаться код любого типа сигнала из приведенных выше в таблицах 7.2 и 7.3. Поле «тип длительности» содержит индекс той строки предварительно определенной в сети доступа таблицы, где указано время, в течение которого сигнал должен оставаться активным. Бит 7 четвертого байта всегда имеет значение 0.
Рис. 7.4. Структура информационного элемента "Время-распознавания"
Сообщения протокола ТфОП передаются в совместно используемых всеми портами ТфОП для этой цели С-каналах (или С-канале). Принимаемые сообщения проверяются, расшифровываются и обрабатываются. Все это вносит случайные задержки и сдвиги между моментами передачи в сеть доступа линейных сигналов, моментами передачи сетью доступа соответствующих сообщений к АТС, моментами передачи от АТС ответных сообщений и моментами реакции сети доступа на эти сообщения. Во избежание неразберихи АТС может потребовать от сети доступа автономно реагировать на некоторые линейные сигналы от абонентского оборудования. Такое требование, передаваемое только от АТС к сети доступа, содержится в информационном элементе «Активизировать-автономную-реакцию-на-сигнал» (Enable-autonomousacknowledge). Длина элемента составляет 4 байта для непрерывных сигналов и от 4 до 6 байтов для импульсных сигналов (рис. 7.5 и 7.6). Для полей «сигнал» и «реакция» используются кодировки, приведенные в таблицах 7.2 и 7.3. В том случае, если реакция является импульсным сигналом, к полям «тип длительности импульса», «индикатор подавления», «индикатор запроса подтверждения» и «число импульсов» применяются правила, которые были определены выше для информационного элемента «Импульсный-сигнал».
Рис. 7.5. Структура информационного элемента "Активизировать-автономную-реакцию-на-сигнал" (реакция в форме "Непрерывный-сигнал")
Рис. 7.6. Структура информационного элемента "Активизировать-автономную-реакцию-на-сигнал" (реакция в форме "Импульсный-сигнал")
АТС может отменить автоматическую реакцию сети доступа с помощью сообщения, содержащего информационный элемент «Деактивизироватъ-автономную-реакцию-на-сигнал» (Disableautonomous-acknowledge). Данный информационный элемент также передается только в сообщении от АТС к сети доступа, а длина его всегда составляет 3 байта.
Некоторые сообщения сети доступа являются реакцией этой сети на последовательность сигналов, требующую, как правило, нескольких сообщений ТфОП. Такие предварительно определенные последовательности могут активизироваться информационным элементом «Автономное-управление-последовательностъю-сигналое» (Autonomous-signalling-sequence). Данный элемент передается только в сообщениях от АТС к сети доступа. Последовательность сигналов определяется с помощью поля «тип последовательности» (sequence type) в битах 1 - 4 (таблица 7.1).
Если сеть доступа должна послать соответствующий предварительно определенной последовательности ответ к АТС, этот ответ дается с помощью информационного элемента «Результатавтономного-управления-последовательностью-сигналов» (Sequence-response).
Имеется ряд информационных элементов, связанных с задачами обнаружения ошибок передачи и технического обслуживания. Для обнаружения ошибок передачи сообщения целесообразно нумеровать. С этой целью в сообщения вводится информационный элемент «Порядковый-номер» (sequence-number), представленный на рис. 7.7. Длина данного элемента всегда равна 3 байтам, и он может передаваться в обоих направлениях.
Рис. 7.7. Структура информационного элемента "Порядковый-номер"
Информационный элемент «Порядковый-номер» должен обязательно присутствовать в сообщениях SIGNAL, PROTOCOL_PARAMETER и SIGNAL_ACK, но не разрешен в других сообщениях. В сообщениях SIGNAL и PROTOCOL_PARAMETER информационный элемент «Порядковый-номер» содержит порядковый номер передачи M(S), а в сообщениях SIGNAL_ACK - порядковый номер приема M(R).
В случае приема достоверного сообщения, которое не имеет смысла в контексте других ранее принятых сообщений, возникает необходимость выяснить состояние процесса в логическом объекте протокола ТфОП по другую сторону интерфейса. Для передачи этой информации служит информационный элемент «Состояние» (State), а причина его передачи указывается в информационном элементе «Причина» (Cause).
Длина информационного элемента «Причина» может составлять 3, 4 или 5 байтов, как это видно из рис. 7.8. Если длина составляет 3 байта, поле диагностики в информационный элемент не включается. Если длина составляет 4 байта, то четвертый байт является диагностическим и указывает идентификатор типа сообщения, вызвавшего передачу информации о причине. Если длина составляет 5 байтов, то диагностическими являются байты 4 и 4а, указывая идентификатор типа сообщения и идентификатор информационного элемента в сообщении, вызвавшего передачу информации о причине. Кодировка информационного элемента «Причина» приведена в таблице 7.7. Все остальные коды зарезервированы.
Рис. 7.8. Структура информационного элемента "Причина" (Cause)
Может случиться так, что сообщение имеет правильный номер, имеет смысл в контексте обмена другими сообщениями, но содержащийся в нем запрос не может быть выполнен из-за отсутствия нужных для этого ресурсов. В такой ситуации в ответное сообщение вводится информационный элемент «Ресурс-недоступен» (Resource-unavailable). Цель данного информационного элемента сообщить АТС о недоступности ресурса, затребованного тем информационным элементом, который скопирован в поле копии возвращаемого к АТС элемента «Ресурс-недоступен». Элемент «Ресурс-недоступен» передается только в сообщениях SIGNAL от сети доступа к АТС. Длина этого элемента зависит от длины возвращаемой копии информационного элемента и может варьировать от 3 до 8 байтов.
7.3. Сообщения протокола ТфОП
Формат сообщения V5 представлен на рис. 6.7 предыдущей главы. Как и для других протоколов V5, сообщения протокола ТфОП состоят из:
а) уникального для протоколов V5 дискриминатора протокола,
б) адреса уровня 3, идентифицирующего порт, к которому относится данное сообщение,
в) типа сообщения,
г) информационных элементов, представляющих сигналы ТфОП или дополнительную информацию. Элементы а), б) и в) являются обязательными для всех сообщений, в то время как перечень информационных элементов г) является специфическим для каждого типа сообщения.
В протоколе ТфОП предусмотрены девять типов сообщений, приведенных в таблице 7.8. Остальные коды типов сообщений протокола ТфОП (согласно таблице 6.4 предыдущей главы) зарезервированы для будущих применений.
Первыми двумя сообщениями ESTABLISH и ESTABLISH_ACK сторона сети доступа и сторона АТС обмениваются при создании сигнального пути в интерфейсе V5. Аналогичным образом, при освобождении сигнального пути производится обмен сообщениями DISCONNECT и DISCONNECT_COMPLETE.
В активной фазе по сигнальному пути идет обмен сообщениями SIGNAL и SIGNAL_ACK. В этой фазе АТС может также регулировать поведение сети доступа путем передачи сообщения PROTOCOL_PARAMETER.
В любой фазе процесса в интерфейсе V5 АТС может передать через интерфейс сообщение STATUS_ENQUIRY, например, если она получает не соответствующее контексту сообщение или по какой-либо другой причине. Сеть доступа передает через интерфейс сообщение STATUS в ответ на сообщение STATUS_ENQUIRY или при получении сообщения, не соответствующего контексту
Далее в этом параграфе рассматриваются функциональное назначение и семантика каждого из вышеупомянутых девяти сообщений. Существенными элементами этого рассмотрения являются краткое описание сообщения, сведения о направлении его передачи (от сети доступа к АТС или от АТС к сети доступа), информационные элементы в порядке их появления в сообщении с указанием обязательности (М) или необязательности (О) наличия этого информационного элемента в сообщении данного типа.
Необходимо отметить, что в сообщениях ESTABLISH, ESTABLISH_ACK, SIGNAL и PROTOCOL_PARAMETER допускается присутствие только одного из указанных необязательных информационных элементов.
Сообщение ESTABLISH, содержание которого представлено в таблице 7.9, соответствует запросу создания сигнального пути для управления исходящим или входящим соединением ТфОП.
Сообщение ESTABLISH_ACK (таблица 7.10) используется для подтверждения того, что логический объект выполнил требуемые действия.
Сообщение ESTABLISH передается либо со стороны АТС (LE) при входящей связи, либо со стороны сети доступа (AN) при исходящей связи. Если в момент создания сигнального пути при исходящей связи нет необходимости в передаче какой-либо дополнительной информации, сеть доступа посылает сообщение AN/ ESTABLISH/-. В качестве альтернативы сеть доступа может послать дополнительную информацию с помощью сообщения AN/ESTABLISH/Steady-signal (непрерывный сигнал). Этим сигналом может быть сигнал о замыкании шлейфа, который можно также передать в следующем сообщении AN/SIGNAL. Пример сценария создания сигнального пути показан на рис. 7.9.
Рис. 7.9. Пример для сообщений ESTABLISH и ESTABLISH_ACK
Если в момент создания сигнального пути при входящей связи необходимость посылки дополнительной информации отсутствует, от входящей АТС передается сообщение LE/ESTABLISH/—. Однако АТС может также передать дополнительную информацию, касающуюся посылок вызова, подачи питания абонентской линии или передачи импульсов. Для посылки обычного вызывного сигнала можно использовать сообщение LE/ESTABLISH/Cadencedringing. Чтобы задать полярность подключаемой к линии батарее, используется сигнал LE/ESTABLISH/Steady-signaLnormal-polarity. Если посылка вызывного сигнала не запрашивается в сообщении LE/ESTABLISH, то ее можно запросить затем в сообщении LE/ SIGNAL.
АТС может действовать и по-другому: активизировать в сети доступа предварительно определенную последовательность обмена сигналами с абонентом путем передачи сообщения LE/ESTABLISH/Autonomous-signalling-sequence. Включение этого элемента в сообщение ESTABLISH предписывает сети доступа самой подать сигнал вызова абоненту и принять сигнал ответа абонента без промежуточного обмена сообщениями с АТС.
Чтобы указать, например, на то, что абонент ответил на входящий вызов, сеть доступа может ответить на сообщение LE/ESTABLISH сообщением AN/ESTABLISH_ACK/Steady-signal:loopclosed. Сеть доступа может ответить и по-другому, с помощью сообщения AN/ESTABLISH_ACK/Pulsed-signal, чтобы запросить применение специальных функций для случая входящей связи с УАТС. Если дополнительную информацию передавать не нужно, сеть доступа отвечает простым сообщением AN/ESTABLISH_ACK/-.
Станция может ответить на сообщение AN/ESTABLISH сообщением LE/ESTABLISH_ACK/Steady-signal, например, для того, чтобы запросить подключение батареи к конкретной абонентской линии. В другом случае станция может ответить сообщением LE/ ESTABLISH_ACK/Pulsed-signal, например, чтобы запросить передачу импульсов тарификации к абоненту, или сообщением LE/ ESTABLISH_ACK/Autonomous signaling-sequence, чтобы активизировать предварительно определенную последовательность обмена сигналами в сети доступа. Если дополнительную информацию передавать не нужно, станция может передать просто сообщение LE/ESTABLISH_ACK/-.
Обмен описанными выше сообщениями создания сигнального пути ориентирован на поддержку управления соединением ТфОП. Если цель другая - информировать станцию об изменении состояния линии, когда соединение не запрашивается, то сеть доступа передает сообщение AN/ESTABLISH/Line-information. Станция подтверждает это сообщение не сообщением LE/ESTABLISHАСК, а сообщением LE/DISCONNECT_COMPLETE.
Сообщение DISCONNECT заканчивает активную фазу сигнального пути и обычно передается станцией, потому что именно она, а не абонентское оборудование управляет разъединением для ТфОП.
Рис. 7.10. Примеры для сообщений DISCONNECT и DISCONNECT_COMPLETE
Сеть доступа отвечает АТС сообщением AN/DISCONNECT_COMPLETE, чтобы указать на согласие с сообщением DISCONNECT. Сообщение AN/DISCONNECT^COMPLETE не содержит дополнительной информации и поэтому не может сообщить станции, положена или снята трубка абонента. Это не составляет проблемы, если освобождение сигнального пути происходит в ответ на сообщение AN/SIGNAL/Steady-signal:on-hook, которое указывает, что линия в данное время свободна или находится в состоянии проверки.
В противном случае сообщить станции о том, что абонент положил трубку, можно, применив модификацию сообщения AN/ ESTABLISH, после чего сеть доступа может сигнализировать о состоянии «трубка положена» с помощью сообщения AN/SIGNAL/ Steady-signaLon-hook. В свою очередь, АТС отвечает сначала сообщением ESTABLISH_ACK, а затем сообщением DISCONNECT. Другие варианты для сети доступа не подходят: для AN/SIGNAL/ Line-signal не рекомендуется использование данного информационного элемента, а сообщение STATUS не подходит потому, что не было получено выпадающих из контекста сообщений.
Чтобы сообщить о том, что абонент положил трубку сразу после приема сетью доступа сообщения LE/ESTABLISH__ACK, можно использовать сообщение AN/DISCONNECT/Steady-signal:on-hook. Если же дополнительная информация не нужна, вместо него можно послать сообщение AN/DISCONNECT/-. Станция завершает процедуру освобождения сигнального пути передачей сообщения LE/DISCONNECT_COMPLETE/Steady-signal или LE/DISCONNECT_COMPLETE/-.
Для активной фазы сигнального пути специфицированы три типа сообщений. Сообщения SIGNAL используются для передачи к АТС информации о состоянии абонентской линии ТфОП и цифр номера или для передачи от АТС инструкций в сеть доступа (таблица 7.11).
Сообщения PROTOCOL _PARAMETER может передавать только АТС для изменения параметра протокола в сети доступа (таблица 7.12).
Эти сообщения подтверждаются сообщениями SIGNAL_ACK (таблица 7.13). Чтобы гарантировать соблюдение последовательности сообщений, все три типа сообщений содержат информационный элемент Sequence-number (Порядковый-номер). В сообщениях SIGNAL и PROTOCOLJPARAMETER3TOT элемент используется для указания порядкового номера сообщения, в котором он передается. В сообщении SIGNAL_ACK его используют для указания номера следующего ожидаемого сообщения и подтверждения правильности приема всех предыдущих сообщений.
Нумерация сообщений используется в процедуре обнаружения ошибок уровня 3, которая будет рассмотрена в параграфе 7.6. Кроме порядкового номера сообщения SIGNAL и PROTOCOL_ PARAMETER содержат еще один необязательный информационный элемент, тип которого зависит от типа передаваемой информации.
Сообщения AN/SIGNAL, передаваемые сетью доступа, могут включать в себя любой из первых пяти (см. таблицу 7.1) типов информационных элементов, кроме Cadenced-ringing (Модулированный-вызов), т.к. сеть доступа не может инициировать вызывной сигнал на станции. Для указания на устойчивое изменение состояния шлейфа линии «шлейф разомкнут» или «шлейф замкнут» можно использовать сообщения AN/SIGNAL/Steady -signal. Для передачи к станции информации о набранных цифрах можно использовать сообщения AN/SIGNAL/Digital-signal. Чтобы информировать станцию об успешной передаче абоненту импульсов тарификации, служат сообщения AN/SIGNAL/Pulse-notification.
Передаваемые от АТС сообщения LE/SIGNAL могут содержать любые из тех же пяти типов информационных элементов, кроме Pulse-notification, поскольку уведомление-о-передаче-импульса (цифры) используется только сетью доступа, чтобы подтвердить доставку импульсов (цифр) абоненту. АТС может затребовать передачу абоненту типового вызывного сигнала путем посылки сообщения LE/SIGNAL/Cadenced-ringing. Ему может предшествовать сообщение LE/SIGNAL/Pulsed-signal:initial-ring. Сообщение LE/SIGNAL/Pulsed-signal можно использовать для передачи абоненту импульсов тарификации.
Станция не может использовать сообщения LE/SIGNAL для передачи информации техобслуживания, поскольку информация о проблемах техобслуживания на другой стороне интерфейса нужна только самой АТС, но она может использовать сообщение LE/ SIGNAL/Autonomous-signalling-sequence, чтобы активизировать в сети доступа автономное управление передачей конкретной последовательности сигналов в направлении УАТС. Тип этой последовательности указывается 4-х битовой комбинацией (табл. 7.10). Сеть доступа может сообщить АТС конечный результат передачи с помощью сообщения AN/SIGNAL/Sequence-response. Конечно, сеть доступа вслед за активизацией автономного управления может передать и другие сообщения, но такое управление может сделать ненужным ожидание ею ответа со стороны станции.
В отличие от станции, сеть доступа может использовать сообщения SIGNAL для передачи информации техобслуживания. С помощью сообщения AN/SIGNAL/Resource-unavailable сеть доступа информирует станцию, что ее запрос не может быть выполнен из-за отсутствия в сети доступа ресурсов, нужных для его выполнения.
Хотя АТС не может использовать сообщение SIGNAL для передачи информации техобслуживания, она может передать такого рода информацию с помощью сообщения PROTOCOL__PARAMETER/Recognition-time. Это сообщение позволяет станции изменить назначенное до этого значение времени распознавания сигналов от абонента. Чтобы задействовать или заблокировать автономную реакцию сети доступа на конкретные абонентские сигналы, станция может использовать сообщения LE/PROTOCOL_PARAMETER/Enable-autonomous-acknowledge и LE/PROTOCOL_PARAMETER/Disable-autonomous-acknowledge. Сеть доступа сообщения PROTOCOL_PARAMETER не передает, т.к. именно АТС, а не сеть доступа отвечает за изменение параметров и за активизацию/деактивизацию автономной реакции сети доступа на сигнал абонента.
Сообщения STATUS и STATUS^ENQWRYny^w для проверки синхронизации процессов на стороне сети доступа и на стороне АТС (таблицы 7.14 и 7.15). Они могут быть полезны в случаях отказов для восстановления синхронизации состояний процесса на обеих сторонах интерфейса V5. Такая проверка может потребоваться при получении сообщения, которое не укладывается в контекст.
Обычно процессы в логических объектах протокола ТфОП на стороне сети доступа и на стороне станции синхронизированы, так что разница между ними до сих пор игнорировалась. Более строго, возможны три разных процесса в логических объектах протокола V5: нормальный процесс, преждевременно прерванный процесс и процесс, обеспечивающий передачу данных о линии.
Все процессы начинаются с нулевого состояния и оканчиваются возвращением в него. Нормальный процесс имеет состояние инициализации и состояние активного сигнального пути. Преждевременно прерванный процесс не достигает состояния активного сигнального пути. Процесс, обеспечивающий передачу данных о линии, имеет только нулевое и информационное состояния.
Станция может инициировать нормальный процесс путем передачи сообщения LE/ESTABLISH. Сеть доступа отвечает передачей сообщения AN/ESTABLISH__ACK и переводит процесс в активное состояние. Сеть доступа может инициировать нормальный процесс путем передачи сообщения AN/ESTABLISH с переходом в состояние инициализации. После приема сетью доступа сообщения LE/ESTABLISH__ACK процесс переходит в состояние активного сигнального пути.
Нормальный процесс заканчивается, когда сеть доступа принимает сообщение LE/DISCONNECT. Данное сообщение (таблица 7.16) используется, чтобы возвратить процесс на стороне сети доступа в нулевое состояние. Сеть доступа отвечает сообщением AN/DISCONNECT_COMPLETE, которое подтверждает, что логический объект протокола на стороне сети доступа выполнил требуемые действия (таблица 7.17).
Преждевременно прерванный процесс начинается как нормальный процесс, инициированный сетью доступа, но затем прерывается вследствие того, что вызывающий абонент дает отбой до появления сообщения LE/ESTABLISH_ACK от АТС. Если сообщение LE/ESTABLISH_ACK принято до завершения прерывания процесса, то сигнальный путь приходит в активное состояние, и процесс продолжается и завершается как нормальный. После приема сообщения LE/ESTABLISH_ACK сеть доступа, приняв сигнал отбоя от абонента, передает сообщение AN/DISCONNECT. Станция отвечает сообщением LE/DISCONNECT_COMPLETE, которое возвращает процесс по обе стороны интерфейса в нулевое состояние.
Процесс передачи данных о линии начинается передачей сообщения AN/ESTABLISH/Line-information. При получении ответного сообщения LE/DISCONNECT сеть доступа возвращает сообщение AN/DISCONNECT_COMPLETE и процесс возвращается в нулевое состояние.
7.4. Протокол ТфОП на стороне сети доступа
Читатель, вероятно, уже обратил внимание на то, что протокол ТфОП описывается подробнее, чем другие протоколы V5. Для этого имеется много причин, частично упоминавшихся в начале главы. Протокол ТфОП, по существу, представляет собой набор инструментальных средств поддержки управления соединениями абонентов ТфОП, причем средства эти используются разными способами при удовлетворении требований разных операторов. Способ, которым используется этот набор инструментальных средств в каждой конкретной сети, специфицирован в «мэппинге» между сигналами ТфОП и сообщениями протокола ТфОП, обычно разном в разных странах, о чем будет сказано несколько позже.
Во всех случаях основная функция протокола - поддержка процесса управления соединениями. Протокол должен также обеспечивать возможность передавать некоторые специальные данные о линии, а также рассмотренные в предыдущем параграфе дополнительные команды, исключающие влияние вносимых самим протоколом задержек и случаев анормального состояния процесса. Сеть доступа несет ответственность за управление специфическими параметрами, такими, как время распознавания аналоговых сигналов, продолжительность, электрические характеристики и частота тарифных импульсов, вызывной ток или отдельные параметры сигналов. Данные параметры устанавливаются аппаратно или программно и должны быть определены заранее, хотя некоторые из них могут быть переопределены с помощью сообщений PROTOCOL_PARAMETER.
На рис. 7.11 представлена структура процесса PANS (PSTN protocol: Access Network Side) в логическом объекте протокола ТфОП на стороне сети доступа, а на рис. 7.12 приведена SDL-диагоамма этого программного процесса.
Сообщения, передаваемые процессом PANS к АТС или принимаемые от нее, подробно обсуждались в двух предыдущих параграфах.
Рассмотрим теперь взаимодействие этого процесса с пользовательским портом ТфОП. Взаимодействие поддерживается функциональными элементами FE (Functional Elements), которые обеспечивают формирование и интерпретацию примитивов, предоставляющих в абстрактном виде обмен необходимой информацией внутри AN между процессом PANS и пользовательским портом.
Имеется четыре группы таких примитивов:
• FE-subscriber_seizure (абонент снял трубку),
• FE-subscriberJ-elease (абонент дал отбой),
• FE-lineJnformation (данные о линии),
• FE-line_signal (линейный сигнал).
Рис. 7.12. SDL-диаграмма процесса PANS (1 из 5)
Рис. 7.12. SDL-диаграмма процесса PANS протокола ТфОП на стороне сети доступа (2 из 5)
Рис. 7.12. SDL-диаграмма процесса PANS (3 из 5)
Рис. 7.12. SDL-диаграмма процесса PANS обработки протокола ТфОП на стороне сети доступа (4 из 5)
Рис. 7.12. SDL-диаграмма процесса PANS обработки протокола ТфОП на стороне сети доступа (5 из 5)
Примитивы трех первых групп передаются (канал С 1) только в направлении от порта к логическому объекту протокола ТфОП. Смысл двух из них очевиден, а третий (FE-line_Jnformation) несет в себе данные о таких изменениях состояния абонентской линии, которые не имеют отношения к сигналам управления соединениями.
Примитивы четвертой группы передаются (каналы С1 и С2) в обоих направлениях, неся в себе сигналы управления соединениями (набор номера, вызывной сигнал и т.п.).
Каналы СЗ и С4 направляют сообщение уровня 3 процесса PANS процессу уровня 2 для передачи каналу ПД.
Процесс PANS имеет 7 состояний:
AN1 — нулевое состояние (null). В этом состоянии процесс ожидает примитива со стороны пользовательского порта или сообщения ESTABLISH со стороны АТС.
AN2 — создание сигнального пути инициировано со стороны сети доступа (path initiated by AN). В это состояние процесс переходит, когда в сети доступа было обнаружено замыкание шлейфа абонентской линии, в сторону АТС было послано сообщение ESTABLISH и от нее ожидается сообщение ESTABLISH_ACK.
AN3 — запрошено преждевременное освобождение сигнального пути (path abort request). Это состояние устанавливается в случае, когда сообщение ESTABLISH было послано к АТС, подтверждение ESTABLISH_ACK от нее еще не получено, а вызывающий абонент дает отбой.
AN4— обрабатываются данные о линии. В это состояние процесс переходит после приема примитива FE-line_information и передачи полученных в нем данных о линии на АТС в сообщении ESTABLISH. Co стороны АТС ожидается сообщение DISCONNECT_COMPLETE. В данное состояние можно перейти только из нулевого состояния AN 1, а выйти из него можно только в нулевое состояние AN 1.
AN5 — состояние активного сигнального пути (path active).
AN 6 — порт блокирован (port blocked). В данное состояние можно перейти из любого состояния, а выйти из него можно только в нулевое состояние, когда порт снова будет готов к работе. (На SDL-диаграмме состояние AN6 не рассматривается, как не рассматриваются и сообщения технической эксплуатации).
AN7 — запрошено освобождение сигнального пути (disconnect request). В это состояние процесс переходит после того, как в сторону АТС передано сообщение DISCONNECT.
Правила представления приведенной на рис. 7.12 SDL-диаграммы процесса PANS соответствуют описанию языка SDL, содержащемуся в главе 2 первого тома и в [55].
В нулевом состоянии AN1 возможно поступление от АТС сообщения ESTABLISH, при получении которого немедленно отправляется подтверждение ESTABLISH_ACK, сбрасываются счетчики и процесс переходит в состояние активного сигнального пути AN5. При переходе в AN5 возможна также, но необязательна передача в пользовательский порт примитива «линейный сигнал» (FE-line_signal). Фактически ESTABLISH — единственное сообщение от АТС, которое выводит процесс PANS из нулевого состояния AN 1.
В состоянии AN1 возможен приход двух других сообщений:
ESTABLISH_ACK и PROTOCOL_PARAMETER, которые не меняют состояние процесса, а вызывают посылку сообщения STATUS к АТС.
Создание сигнального пути может идти также по инициативе абонента, когда из пользовательского порта поступает примитив FE-subscriber-seizure, сообщающий о том, что абонент снял трубку. В этом случае запускается таймер Т 1 и к АТС направляется сообщение ESTABLISH, а процесс переходит в состояние AN2 -создание сигнального пути инициировано сетью доступа. Если используется автономная реакция на сигнал абонента, то в обратном направлении к порту передается примитив FE-line_signal. В других случаях (когда автономная реакция на сигнал от абонента не активизирована) FE-line_signal не передается.
При поступлении от пользовательского порта примитива «данные о линии» (FE — line information) запускается таймер Т 1, к АТС посылается сообщение ESTABLISH с информационным элементом «данные о линии», а процесс переходит в состояние AN4 (данные о линии обрабатываются).
В состоянии AN2 от АТС ожидается сообщение ESTABLISH_ACK, при приеме которого сбрасываются все таймеры, а процесс переходит в состояние активного сигнального пути AN5. Вместо ESTABLISH_ACK может придти сообщение PROTOCOL_PARAMETER, в ответ на которое направляется информация о статусе, а процесс остается в том же состоянии AN2. Возможно также поступление сообщения DISCONNECT_COMPLETE, при приеме которого сбрасываются таймеры, все параметры устанавливается в исходное состояние, а процесс возвращается в нулевое состояние AN 1. Если от АТС в состоянии AN2 поступает сообщение ESTABLISH, то дальнейшие действия зависят от того, какой вызов имеет приоритет — входящий или исходящий. В случае приоритета исходящего вызова это сообщение просто игнорируется, а процесс остается в состоянии AN2. Если же приоритет имеет входящий вызов, то к АТС посылается сообщение ESTABLISH__ACK, устанавливаются все счетчики, сбрасываются все таймеры, а в пользовательский порт передается примитив FE-line_signal. Процесс переходит в состояние AN5 активного сигнального пути.
В этом же состоянии AN2 абонент может положить трубку Тогда из пользовательского порта поступит примитив FE-subscriber_release («отбой абонента»), и процесс перейдет в состояние AN3 (запрошено преждевременное освобождение сигнального пути - PATH ABORT REQUEST). В состоянии AN2 может также сработать таймер Т 1, если в течение периода Т 1 не придет ответ на ранее посланное сообщение ESTABLISH. В этом случае к АТС повторно посылается сообщение ESTABLISH, запускается таймер Т2, а процесс остается в том же состоянии AN2. Точно то же происходит при срабатывании таймера Т2: повторная передача сообщения ESTABLISH и пускТ2.
В состоянии AN3 возможно повторное занятие, если абонент АТС снова снял трубку до того как поступило сообщение ESTABLISH_ACK или DISCONNECT^COMPLETE. В этом случае процесс возвращается в состояние AN2. В том же состоянии AN3 возможен приход практически любого другого сообщения от АТС. Это может быть сообщение PROTOCOL_PARAMETER, в ответ на которое посылается сообщение STATUS, а процесс не меняет своего состояния. Возможен приход сообщения DISCONNECT_COMPLETE, которое переводит процесс в состояние AN1. Возможен приход уже опоздавшего и не ожидаемого более сообщения ESTABLISH_ACK, в ответ на которое отправляется сообщение DISCONNECT, сбрасываются таймеры Т1 и Т2, и запускается таймер ТЗ, а процесс переходит в состояние AN7 (запрошено освобождение сигнального пути). В случае прихода сообщения ESTABLISH выясняется, какой вызов является приоритетным — входящий или исходящий. Если приоритет имеет исходящий вызов, процесс остается в том же состоянии. В случае приоритета входящего вызова направляется сообщение ESTABLISH_ACK, устанавливаются все счетчики, сбрасываются таймеры Т1/Т2, а процесс переходит в состояние активного сигнального пути AN5.
В состоянии AN4 (данные о линии обрабатываются) ожидается сообщение DISCONNECT__COMPLETE, которое сбрасывает таймеры и переводит процесс в нулевое состояние AN I. В случае, если в течение периода Т 1 сообщения DISCONNECT__COMPLETE не поступило, стартует таймер Т2 и повторяется посылка сообщения ESTABLISH, а процесс остается в том же состоянии AN4.
В состоянии AN5 активного сигнального пути выполняются обычные функции абонентской сигнализации. Со стороны АТС в этом состоянии может придти сообщение DISCONNECT_COMPLETE, которое переводит процесс в нулевое состояние AN I. Может также придти рассмотренное выше сообщение SIGNAL, при приеме которого осуществляется проверка порядкового номера принятого сообщения. Если этот номер является правильным, то сигнал транслируется в виде примитива FE-line_signal в пользовательский порт, увеличивается на 1 счетчик S(R), и запускается таймер Тr, если он не был запущен ранее. Процесс при этом остается в том же состоянии AN5. Если же порядковый номер принятого сообщения SIGNAL неверен, то к АТС отправляется сообщение DISCONNECT, запускается таймер ТЗ, сбрасываются таймеры Т1 и Т2, а процесс переходит в состояние AN7. Аналогичным образом происходит анализ правильности принятого порядкового номера при приходе сообщения SIGNAL_ACK. Если номер сообщения M(R) правильный, то сбрасывается таймер Tt, а процесс остается в состоянии активного сигнального пути AN5. В случае, если номер неправильный, процесс переходит в состояние AN7. Практически таким же образом обрабатывается сообщение PROTOCOL_PARAMETER. И, наконец, от пользовательского порта может придти примитив FE-line_signal, при приеме которого к АТС направляется сообщение SIGNAL, увеличивается на 1 счетчик S(S), выполняются анализ и другие действия, предусмотренные в алгоритме на рис. 7.12. При срабатывании таймера Tt процесс посылает сообщение DISCONNECT, запускает таймер ТЗ и переходит в состояние AN7. В случае срабатывания таймера Тг посылается сообщение SIGNAL_ACK, а процесс остается в том же состоянии AN5.
В состоянии AN7 возможен приход одного из двух сообщений: DISCONNECT или DISCONNECT_COMPLETE, в результате приема которых сбрасываются все таймеры, параметры протокола устанавливаются в исходное состояние, а процесс переходит в нулевое состояние AN1. При отсутствии сигнала DISCONNECT и срабатывании таймера ТЗ существенное значение имеет количество срабатываний ТЗ: первые два раза при срабатывании таймера посылается сигнал DISCONNECT и заново спускается этот же таймер ТЗ, а на третий раз процесс принудительно переводится в нулевое состояние AN1 с посылкой аварийного сообщения в систему управления.
В приведенном выше описании опущено одно чрезвычайно важное обстоятельство: в ряде случаев время реакции на сигнал от абонента ТфОП критично, и тогда сеть доступа должна реагировать автономно, что необходимо, например, для выключения вызывного сигнала и для прекращения передачи сигнала ответа станции. Возможны другие варианты реакции, критичные с точки зрения времени, которые определяются в спецификации «мэппинга» национального протокола ТфОП.
Для рассмотренной выше на рис. 7.12 SDL-диаграммы процесса PANS приняты следующие значения таймеров:
• таймер Т 1=4 с — останов после приема сообщения ESTAB-
LISH_ACK или сообщения DISCONNECT_COMPLETE.
После срабатывания этого таймера повторяется посылка сообщения ESTABLISH и запускается таймер Т2;
• таймер Т2==(5-30 с) - останов после приема сообщения ESTABLISH_ACK или сообщения DISCONNECT_COMPLETE. Запускается многократно до приема отбоя абонента;
• таймер Т3=2 с - останов после приема сообщения DISCONNECT или DISCONNECT_COMPLETE. Запускается многократно. После 3-го запуска в систему управления передается сигнал индикации ошибки;
• таймер Тг=5 с - запускается после приема сообщения SIGNAL или сообщения PROTOCOL_PARAMEMER;
• таймер Tt= 10 с - запускается после передачи сообщения SIGNAL.
7.5. Протокол ТфОП на стороне АТС
АТС отвечает за управление соединением абонента ТфОП и предоставление ему дополнительных услуг. Передатчики и приемники многочастотного набора номера (DTMF), генераторы акустических сигналов и автоинформаторы размещаются в АТС, следовательно, адресная информация с использованием DTMF должна передаваться «прозрачно» между портом пользователя и АТС. В то же время сигнализация о состоянии линии должна интерпретироваться в сети доступа и затем передаваться через интерфейс V5 посредством сообщений уровня 3, как было показано в предыдущих параграфах.
На рис. 7.13 представлена структура процесса PLES (PSTN protocol: Local Exchange Side) в логическом объекте протокола ТфОП на стороне АТС, а на рис. 7.14 приведена SDL-диаграмма этого программного процесса. По аналогии со стороной сети доступа взаимодействие этого процесса с логическим объектом национального протокола управления соединениями ТфОП поддерживается функциональными элементами FE, которые обеспечивают формирование и интерпретацию примитивов, представляющих в абстрактной форме обмен необходимой информацией внутри LE между процессом PLES и национальным протоколом ТфОП (каналы С7 и С8). Так же как на SDL-диаграмме протокола ТфОП на стороне сети доступа, здесь не показано взаимодействие с системой управления.
Имеются следующие группы примитивов:
— примитивы создания сигнального пути в интерфейсе V5:
FE-establish_request, FE-establish_indication, FE-establish_acknowledge, FE-establish_acknowledge_indication;
— примитивы сигнализации:
FE-line_signal_request, FE-line_signal_indication;
— примитивы освобождения сигнального пути в интерфейсе V5:
FE-disconnect_request,
FE-disconect_complete_request,
FE-disconnect__complete_indication;
— примитивы управления параметрами протокола ТфОП:
FE-protocol__parameter_request.
Смысл и содержание перечисленных примитивов станут ясны читателю при рассмотрении SDL-диаграммы процесса PLES. Здесь же полезно отметить, что все примитивы типа indication передаются процессом PLES логическому объекту национального протокола ТфОП, а все примитивы типа request (и примитив FEestablish__acknowledge, имеющий тип response) — в обратном направлении.
Процесс PLES алогическом объекте протокола ТфОП на стороне АТС имеет следующие состояния:
LE1 — нулевое состояние (null).
LE2— создание сигнального пути инициировано со стороны АТС (path initiated by LE). Процесс переходит в это состояние после того, как АТС передаст к сети доступа сообщение ESTABLISH.
LE3 — создание сигнального пути инициировано со стороны сети доступа (path initiated by AN). Сеть доступа послала сообщение ESTABLISH к АТС и ожидает в ответ сообщение ESTABLISH_ACK.
LE4— состояние активного сигнального пути (path active), в котором он поддерживает обычные функции сигнализации ТфОП для данного порта.
LE5— запрошено освобождение сигнального пути (path disconnect request). В это состояние процесс переходит, когда АТС посылает в сеть доступа сообщение DISCONNECT. Выход изданного состояния возможен, когда сеть доступа передаст ответное сообщение DISCONNECT_COMPLETE.
Собственно говоря, данный перечень состояний уже косвенно содержит описание процесса PLES, SDL-диаграмма которого приведена на рис. 7.14. В дополнение к этому перечню и к самой SDL-диаграмме полезно рассмотреть значения таймеров, используемые процессом PLES:
• таймер Т1 =2 с — запускается после передачи сообщения ESTABLISH или DISCONNECT__COMPLETE. Сброс таймера происходит при поступлении сообщения ESTABLISH_ACK. Если же таймер сработает до наступления этого события, повторяется посылка сообщения ESTABLISH, и таймер Т1 перезапускается. При повторном срабатывании таймера Т1 до поступления сообщения ESTABLISH__ACK к сети доступа направляется сообщение DISCONNECT и запускается таймер ТЗ;
• таймер Т3=2 с — запускается после передачи сообщения DISCONNECT. Запускается многократно. При срабатывании этого таймера в состоянии LE5 процесса PLES (как это имело место и в состоянии AN7 процесса PANS) в зависимости от того, сколько раз сработал таймер ТЗ, принимается решение в пользу одного из двух вариантов:
• если таймер сработал до 3 раз, повторяется передача сообщения DISCONNECT;
• после третьего срабатывания таймера передается сигнал индикации ошибки в систему управления;
• таймер Т4=2 с - запускается после приема сообщения STATUS-ENQUIRY. Запускается многократно;
• таймер Тг=5 с - запускается после передачи сообщения SIGNAL;
• таймер Tt= 10 с - запускается после передачи сообщения SIGNAL или PROTOCOL_PARAMETER.
Рис. 7.14. SDL-диаграмма PLES обработки протокола ТфОП на стороне АТС (1 из 3)
Рис. 7.14. SDL-диаграмма PLES обработки протокола ТфОП на стороне АТС (2 из 3)
Рис. 7.14. SDL-диаграмма PLES обработки протокола ТфОП на стороне АТС (3 из 3)
Как это неоднократно делалось в большинстве глав первого тома, место, сэкономленное за счет описания процесса PLES с помощью SDL-диаграммы, представляется полезным отдать некоторым примерам, в которых действуют оба рассмотренных процесса PANS и PLES. Рассмотрим примеры [83] сообщений создания сигнального пути:
• сообщение AN/ESTABLISH/Steady-signaLoff-hook используется для создания сигнального пути в случае исходящего вызова после того, как вызывающий абонент снял трубку;
• сообщение LE/ESTABLISH/Cadenced-ringing используется для создания сигнального пути в случае входящего вызова и предписывает передать абоненту вызывной сигнал, если нет конфликта между входящим и исходящим вызовами;
• сообщение LE/ESTABLISH/Steady-signal:normal-polarity используется для создания сигнального пути в случае входящего вызова, когда имеет место конфликт и приоритет отдается входящему вызову.
Примеры сообщений освобождения сигнального пути.
• сообщение LE/DISCONNECT/- генерируется, когда решение освободить сигнальный путь принимает станция; в результате процесс PANS переходит в нулевое состояние AN1;
• сообщение AN/DISCONNECT/- генерируется, когда абонент кладет трубку до того, как процесс PANS получит сообщение LE/ESTABLISH_ACK/- в ответ на сообщение AN/ESTABLISH/Steady-signaLoff-hook;
• сообщения AN/DISCONNECT^COMPLETE/- и LE/DISCONNECT_COMPLETE/- генерируются автоматически при получении сообщений DISCONNECT;
• Сообщения AN/ESTABLISH_ACK/- и LE/ ESTABLISH,. АСК/— генерируются автоматически при получении сообщений ESTABLISH. Примеры сообщения SIGNAL:
• сообщение AN/SIGNAL/Digit-signal:value+no-acknowledgement генерируется, когда сеть доступа обнаруживает цифры, набранные абонентом;
• сообщение AN/SIGNAL/Steady-signal:off-hook генерируется, когда абонент снимает трубку в ответ на входящий вызывной сигнал;
• сообщение LE/SIGNAL/Steady-signal'.normal-polarity генерируется, когда станция дает команду прекратить вызывной сигнал в ответ на снятие трубки абонентом;
• сообщение LE/SIGNAL/Steady-signaLstop-ringing генерируется, когда станция принимает решение прекратить вызывной сигнал по причине иной, чем реакция на сигнал снятия трубки.
7.6. Процедуры протокола ТфОП
В двух предыдущих параграфах данной главы в рамках описаний процессов PANS и PLES рассмотрены две основные группы процедур протокола ТфОП.
В первую очередь это процедуры, связанные с поддержкой управления соединениями ТфОП. Основное назначение данных процедур — создать сигнальный путь для передачи линейных сигналов между аналоговым портом ТфОП сети доступа и национальным протоколом ТфОП АТС. Для создания сигнального пути используются функциональные процедуры, которые обеспечивают синхронизацию работы через интерфейс V5 логических объектов сети доступа и АТС, а также возможность разрешать конфликты, связанные с перегрузкой АТС и со встречными вызовами. Как уже упоминалось выше, содержимое примитивов FE-line__signal, передаваемых аналоговым портом ТфОП, не должно интерпретироваться протоколом V5, т.е. соответствующая информация должна передаваться через интерфейс V5 «прозрачно».
Другую группу составляют процедуры, не связанные с поддержкой управления соединениями ТфОП, т.е. не имеющие прямого отношения к установлению сигнального пути. Эти процедуры позволяют сети доступа изменить некоторые параметры протокола, блокировать или разблокировать порты пользователя и производить необходимые действия при рестарте.
Существуют еще две группы процедур, которые явно не рассматривались в предыдущих параграфах, но применение которых абсолютно обязательно для протокола ТфОП. Одну такую группу составляют процедуры обнаружения ошибочных ситуаций, которые обрабатывают каждое получаемое протокольным объектом интерфейса V5 сообщение.
Как правило, все сообщения должны содержать, по меньшей мере, дискриминатор протокола, адрес уровня 3 и информационный элемент типа сообщения. Если принимаемое сообщение содержит менее 4 байтов, принимающая сторона (сеть доступа или АТС) должна передать системе эксплуатационного управления сообщение об ошибке и проигнорировать принятое сообщение. В данном контексте термин «игнорировать сообщение» означает, что с содержимым сообщения (заголовком сообщения и его информационными элементами) никаких действий не производится.
Если в сообщении обнаружено более трех необязательных информационных элементов, сообщение считается слишком длинным и оставшаяся после третьего необязательного информационного элемента часть должна быть отброшена. Предполагается, что вся отброшенная информация является повторением оставшихся необязательных информационных элементов.
Ошибочная ситуация фиксируется, если логический объект протокола ТфОП на стороне сети доступа принимает сообщение с дискриминатором протокола, кодирование которого отличается от приведенного в главе 6. В этом случае генерируется сигнал индикации внутренней ошибки, данное сообщение игнорируется и передается сообщение STATUS с информационным элементом «Состояние», указывающим на текущее состояние процесса, и информационным элементом «Причина», указывающим код ошибки (код 0000001 — ошибка в дискриминаторе протокола). При приеме такого же ошибочного сообщения логическим объектом на стороне АТС данное сообщение игнорируется и генерируется сигнал индикации внутренней ошибки.
Ошибка адреса уровня 3 фиксируется, если адрес закодирован не по правилу, определенному выше в данной главе, если значение не распознано или не соответствует существующему порту доступа ТфОП. Ошибка в информационном элементе типа сообщения означает, что принято нераспознанное сообщение (не используемое или несуществующее). В обоих случаях сообщение игнорируется и генерируется сигнал индикации ошибки.
Информационный элемент переменной длины, имеющий код, значение которого меньше, чем значение кода предшествовавшего ему информационного элемента переменной длины, считается выпавшим из нормальной последовательности. Если такое случается, то на стороне сети доступа этот информационный элемент удаляется, а обработка сообщения продолжается. Сеть доступа также генерирует сообщение о внутренней ошибке и передает сообщение STATUS с информационным элементом «Состояние», указывающим текущее состояние процесса, и с информационным элементом «Причина» со значением «информационный элемент, принятый с нарушением очередности следования».
Если в сообщении повторяется один и тот же обязательный информационный элемент, логический объект V5 на стороне сети доступа должен игнорировать это сообщение, сформировать сообщение о внутренней ошибке и передать сообщение STATUS с информационным элементом «Состояние», указывающим текущее состояние процесса, и с информационным элементом «Причина» со значением «повторяющийся обязательный информационный элемент» и с соответствующей диагностикой, алогический объект на стороне АТС должен игнорировать данное сообщение и сформировать сообщение о внутренней ошибке.
Если в сообщении повторяется необязательный информационный элемент, то повторный элемент удаляется, продолжается обработка сообщения, генерируется сообщение о внутренней ошибке и передается сообщение STATUS с информационным элементом «Состояние», указывающим текущее состояние процесса, с информационным элементом «Причина» со значением «повторение необязательного информационного элемента» и с соответствующей диагностикой.
Процедуры этого типа также обрабатывают ошибки, состоящие в пропуске обязательного информационного элемента в принятом сообщении, в приеме нераспознанного информационного элемента, ошибки в содержании обязательного или необязательного информационных элементов, а также ошибки, состоящие в приеме непредвиденных сообщений, неразрешенных необязательных информационных элементов и т.п.
После того как сообщение проверено с помощью процедур обработки ошибок и если оно не должно игнорироваться, то должны выполняться нормальные процедуры, как это изложено в параграфах 7.4 и 7.5 данной главы.
И, наконец, процедура обнаружения ошибок уровня 3 позволяет уровню 3 обнаружить ошибку при передаче сообщений, которые не защищены от ошибок функциональной частью протокола. Сообщения SIGNAL и PROTOCOL_PARAMETER, содержащие информацию примитивов FE-line_signal и FE-protocol_parameter, соответственно, защищаются от ошибок механизмом, описанным ниже.
С точки зрения этого механизма сообщения SIGNAL и PROTOCOL_PARAMETER неразличимы: они вместе рассматриваются как единая последовательность нумерованных сообщений, и для подтверждения приема сообщений, образующих такую последовательность (независимо от их типа), используются сообщения SIGNAL_ACK. (Речь, разумеется, идет о сообщениях, передаваемых от АТС, поскольку сообщения PROTOCOL_PARAMETER сетью доступа не передаются.)
Все сообщения из этой единой последовательности нумеруются по модулю 128, т.е. номер может иметь значение от 0 до 127. На каждой стороне интерфейса V5 имеется счетчик передаваемых сообщений, текущее показание которого S(S) обозначает порядковый номер подлежащего передаче сообщения. С появлением следующего сообщения, подлежащего передаче, S(S) увеличивается на 1.
На каждой стороне интерфейса имеется счетчик подтвержденных сообщений, текущее показание которого S(A) обозначает номер последнего из переданных сообщений, прием которого подтвержден адресатом, т.е. равноправным логическим объектом, которому оно было послано. Полезно заметить, что разность S(S)— S(A) не должна превышать максимального числа сообщений, находящихся в очереди на передачу.
Каждому передаваемому сообщению, принадлежащему рассматриваемой единой последовательности, присваивается порядковый номер M(S). В момент, когда сообщение должно передаваться, в поле информационного элемента «порядковый номер», входящего в состав этого сообщения, помещается значение M(S), равное текущему S(S).
В логическом объекте уровня 3 на той и на другой стороне интерфейса имеется также счетчик, текущее показание которого S(R) обозначает порядковый номер очередного ожидаемого на приеме сообщения. С приемом сообщения, M(S) которого равен S(R), показание счетчика S(R) увеличивается на 1.
В момент, когда должно передаваться подтверждающее сообщение, в поле информационного элемента «порядковый номер», входящего в состав этого сообщения, помещается порядковый номер ожидаемого сообщения M(R), причем значение M(R) устанавливается равным S(R). Сторона, принявшая подтверждающее сообщение, определяет состоятельность полученного M(R), проверяя условие S(A) J M(R) J S(S).
Как это показано на SDL-диаграммах процессов PANS и PLES в данной главе, программные счетчики связаны с таймерами этих процессов. Если S(S) превышает допустимую величину, таймеры Tt и Тr должны быть остановлены и должно также передаваться сообщение DISCONNECT. Если величина S(S) корректна и таймер Tt работает, то никаких действий не предпринимается, а если таймер Tt не был запущен, то это должно быть сделано.
На тех же SDL-диаграммах видно, что при каждой подготовке передачи уровнем 3 сообщения SIGNAL_ACK порядковый номер ожидаемого сообщения M(R) должен принимать текущее значение переменной S(R). При каждом приеме уровнем 3 сообщения SIGNAL значение M(S) должно сравниваться со значением S(R). Если M(S) равно S(R), сообщение должно быть принято, а значение S(R) - увеличено на 1. Если M(S) не равно S(R), таймеры Tt и Тr должны прекратить работу и должно быть передано сообщение разъединения.
При каждом приеме сообщения SIGNAL__ACK номер M(R) проверяется. Если M(R) не состоятелен, таймеры Tt и Тr сбрасываются и передается сообщение DISCONNECT. Если M(R) является корректным, счетчик подтвержденных сообщений принимает значение S(A), равное M(R).
Если S(A) равно S(S), таймер Tt сбрасывается. Если S(A) не равно S(S) и если значение M(R) является корректным, таймер Tt перезапускается. Таймер Tt сбрасывается при каждом приеме сообщения SIGNAL_ACK, значение M(R) в котором равно S(S).
7.7. Национальные спецификации протокола ТфОП
По аналогии с параграфом 4.7, посвященным протоколу DSS-1, представляется полезным отметить некоторые особенности протокола ТфОП интерфейса V5, принятые в России. Российские национальные спецификации V5 базируются на стандартах ETSI. При этом взаимосвязь протокола ТфОП интерфейса V5 с собственно системами сигнализации по абонентским линиям (национальный мэппинг), как и в других странах, специфицируется национальной администрацией связи. Кроме того, определяется перечень сообщений и параметров протокола ТфОП, применяемых в национальной версии протокола.
В отличие от большинства европейских и американских сетей связи ситуация в российской ТфОП в этом плане сложилась весьма удачная. Отсутствие экзотических «предISDNовских» интерфейсов, простота и унификация абонентских систем сигнализации, рассмотренных в главе 1, привели к тому, что национальная российская версия протокола ТфОП является фактически подмножеством возможностей, предлагаемых стандартом ETSI. Перечень сигналов, передаваемых по абонентской линии и поддерживаемых протоколом ТфОП интерфейса V5, приведен в таблице 7.18.
В национальной версии протокола ТфОП применяется набор сообщений и параметров, приведенный в таблице 7.19. Для каждого сообщения показаны те необязательные информационные элементы, которые могут входить в его состав. Кроме того, если для каких-либо параметров информационных элементов нормирован диапазон допустимых значений, более узкий, чем предусмотрено ETSI, в таблице указаны возможные значения этих параметров.
Содержание таблицы 7.19 требует некоторых примечаний:
1) Данный информационный элемент используется для идентификации номера вызывающего абонента по алгоритму, принятому в ряде зарубежных стран (с использованием посылок кодом DTMF). Практически этот информационный элемент в России не используется, и включение его в национальные спецификации несколько условно. Что же касается рассмотренной в первом томе процедуры идентификации номера вызывающего абонента (АОН), то поскольку запросы АОН осуществляются имитацией сигнала ответа с передачей частоты 500 Гц по разговорному каналу, то для такой процедуры интерфейс V5 является прозрачным.
2) Данный информационный элемент используется, чтобы стимулировать выполнение оборудованием сети доступа некоторой, заранее определенной последовательности действий. Обычно этот информационный элемент применяется для реализации последовательностей действий, критичных по времени, когда нецелесообразно перегружать АТС посылкой в сторону сети доступа многочисленных, следующих подряд сигналов или когда нужно избавить ресурсы АТС от обработки длительных событий (например, при плохо повешенной трубке). Элемент передается только в сторону сети доступа и содержит указание передать в сторону абонента сигнальную последовательность конкретного типа. Код типа последовательности сигналов определяется 4-битовой комбинацией. Код «ООО 1 » соответствует сигналу блокировки абонентской линии.
3) Применяется в качестве ответа на сигнал блокировки абонентской линии.
4) Сигнал используется для переноса в сторону АТС запроса дополнительных услуг, посылается при нажатии абонентом кнопки «R» (калиброванный разрыв шлейфа) или «1» в разговорной фазе соединения ТфОП.
5) Данные сигналы используются для управления кассированием монет в таксофонах. После ответа вызываемого абонента со стороны станции посылается сигнал, предписывающий произвести переполюсовку напряжения на проводах абонентской линии, благодаря чему начинается кассирование монет. В случае таксофона с централизованным управлением кассирование следующей монеты происходит при восстановлении полярности напряжения и новой переполюсовке, для чего в сторону сети доступа посылаются соответствующие сигналы. Таксофон с автономным управлением сам вырабатывает сигналы кассирования. По окончании разговора полярность напряжения на проводах абонентской линии восстанавливается.
6) Этот сигнал АТС передает с целью указать, при какой длительности разрыва шлейфа он должен истолковываться оборудованием сети доступа как калиброванный разрыв, используемый для обращения к дополнительным услугам.
Ограниченный объем книги не позволяет привести SDL-диаграммы, отражающие функционирование протокола ТфОП применительно к сети связи России. Имеет смысл упомянуть лишь наиболее характерные национальные особенности алгоритма управления соединениями ТфОП при использовании интерфейса V5.
Так, из нескольких возможных вариантов определены конкретные алгоритмы отбоя. В случае отбоя со стороны АТС абоненту через сеть доступа передается акустический сигнал «Занято». После того как абонент повесит трубку, в сторону АТС передается сообщение AN/SIGNAL/Steady_signal:On_hook. В ответ на это сообщение посылается сообщение LE/DISCONNECT, которое подтверждается сообщением AN/DISCONNECT_COMPLETE.
В случае, если отбой происходит со стороны сети доступа, в сторону АТС сразу передается сообщение AN/SIGNAL/Steady_signal:0n_hook, а дальнейший алгоритм отбоя полностью аналогичен описанному выше.