Файл: Book2 Full.doc

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.

Как это неоднократно делалось в большинстве глав первого тома, место, сэкономленное за счет описания процесса 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 с информационным элементом «Состояние», указывающим текущее состояние процесса, с информационным элементом «Причина» со значением «повторение необязательного информационного элемента» и с соответствующей диагностикой.