Главная  Системы коммутации 

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [ 69 ] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103]

Поскольку для каждого ID диалога существует свое пространство имен ID обращений, один и тот же ID обращения может повторяться в разных диалогах. Структурированный диалог предполагается двусторонним - на фазе его продолжения возможен дуплексный обмен компонентами.

Подуровень CSL предусматривает организацию соответствия между запросами и откликами. Связанное с запросом операции значение ID обращения вводится в отклик на этот запрос. Возможны 4 класса операций:

• класс 1 - предусматривается отклик и при удаче, и при неудаче,

• класс 2 - предусматривается отклик только в случае неудачи,

• класс 3 - предусматривается отклик только в случае удачи,

• класс 4 - отклик не нужен ни в том, ни в другом случае.

Смысл и содержание каждого компонента определяется его типом. Существуют компоненты следующих пяти типов.

• INVOKE - обращение. Этот компонент запрашивает выполнение встречной стороной определенной операции. Он может быть связан с другой операцией, к которой обращалась встречная сторона.

• RETURN RESULT (NOT LAST) - часть данных с информацией о результате выполнения операции. Имеется в виду, что все данные с информацией о результате не могут быть целиком размещены в одном компоненте, так что ТС-пользователю пришлось разделить их на несколько сегментов. Данный компонент содержит один из этих сегментов, за которым последуют другие.

• RETURN RESULT (LAST) - последняя (или единственная) часть данных с информацией о результате выполнения операции. Этот компонент свидетельствует о том, что операция успешно завершена.

• RETURN ERROR - успешно завершить операцию не удалось. Этот компонент содержит информацию о причине того, что операция не была завершена.

• REJECT - отказ в приеме к обработке компонента, поступившего от встречной стороны. Компонент содержит информацию о причине отказа - либо отсутствие ресурсов, нужных для выполнения операции, либо наличие в поступившем компоненте той или иной ошибки (компонент неизвестного типа, с нестандартной или не соответствующей случаю структурой, с недопустимым или используемым для другой операции идентификатором обращения, с неизвестным кодом операции, и т п.)

Рассмотрим теперь функции и услуги подуровня транзакций (TSL) Оч(>видно, что р 1Г1юложеии1.1и ньиле подуровоиь CSL являет



ся пользователем подуровня TSL (или, для краткости, TSL пользе вателем); другие TSL-пользователи в настоящее время не опреде лены, однако подуровень TSL устроен так, что они, в принципе, могут существовать.

TSL предусматривает средства, поддерживающие обмен компонентами между TSL-пользователями и обеспечивающие использование услуг нижележащих уровней (подсистем SCCP и МТР) для двустороннего переноса через сеть ОКС сообщений между двумя взаимодействующими подсистемами ТС, размещенными в разных пунктах этой сети.

Поддержка неструктурированного диалога TSL-пользователей заключается в том, что TSL обеспечивает передачу сообщения, содержащего один или несколько компонентов (связанных с операциями класса 4), от «своего» TSL-пользователя, являющегося отправителем, KTSL-пользователю, являющемуся адресатом. Если для поддержки такого диалога требуется передать несколько TSL-сообще-ний, логическая связь между ними (то есть их принадлежность одной и той же транзакции) в явном виде не определяется.

Поддержка структурированного диалога базируется на том, что каждый TSL-пользователь идентифицирует транзакцию уникальным ID транзакции, который присутствует во всех TSL-сообщениях, относящихся к этой транзакции. Для каждой транзакции TSL-пользо-ватель указывает ее начало, продолжение и окончание; на фазе продолжения возможен дуплексный обмен между TSL-пользователями сообщениями «внутри» этой транзакции.

Отметим, что в настоящее время специфицированы средства транзакций, использующие только такие услуги SCCP, которые не предусматривают создание в сети ОКС сигнальных соединений. Использование услуг, ориентированных на сигнальные соединения, изучается ITU-T.

8.4.4 Подсистема ISUP

Подсистема ISUP - это подсистема-пользователь MTR поддерживающая межстанционную сигнализацию в ТфОП и в ISDN. При поддержке сигнализации в ISDN ISUP пользуется также услугами SCCP, как это показано на рис. 8.6.

Средства адресации МТР дополнены в ISUP идентификатором канала, поскольку для того, чтобы указать, к какому телефонному соединению относится сообщение, ISUP указывает номер того канала, который занят в этом соединении. Дело в том, что ISUP реализует два метода сигнализации - эстафетный, когда сообщение передается от одной станции к другой и на промежуточных станциях может изменяться, и скво jhom, когда обмен сообщениями происхо



дит между конечными точками соединения. Сквозной метод обычно использует услуги SCCP - либо без создания сигнального соединения, либо ориентированные на соединение; в последнем случае процедуры значительно упрощаются.

Сообщений ISUP слишком много, чтобы рассмотреть их все в этой, и так самой длинной главе учебника. Назовем лишь основные категории сообщений:

• Сообщения управления базовым соединением

• Сообщения управления дополнительными услугами

• Сообщения модификации соединения во время связи

• Сообщения эксплуатационного контроля и управления

• Сквозные сообщения

Принципы форматирования сообщений в ISUP подобны принципам, принятым в SCCP и описанным в п- 8.4.2 (в этом легко убедиться, сравнив приводимый ниже рис.8.11 с рис.8.9). Однако ЗССРуст-роена так, что маршрут, по которому проходит «сквозное» сигнальное сообщение, никак не связан с маршрутом, по которому проходит соединение телефонных каналов, а ISUP опирается на «канальный» подход идентификации транзакции

МАРШРУТНАЯ ЭТИКЕТКА

ИДЕНТИФИКАТОР КАНАЛА

тип СООБЩЕНИЯ

ОБЯЗАТЕЛЬНАЯ ЧАСТЬ

ФИКСИРОВАННОЙ длины

ОБЯЗАТЕЛЬНАЯ ЧАСТЬ ПЕРЕМЕННОЙ длины

НЕОБЯЗАТЕЛЬНАЯ ЧАСТЬ

Рис. 8.11 Структура сообщения ISUP

Теперь рассмотрим пример установления базового соединения в ISDN. В этом примере (рис.8.12) терминал вызывающего пользователя А передает по каналу D в интерфейсе UNI сообщение 0.931 SETUP в сторону своей АТС (исходящей), которая анализирует его, удостоверяется в его правильности и передает начальное адресное сообщение IAM протокола ISUP к той транзитной АТС, через которую, согласно таблице маршрутизации исходящей АТС, должно пройти устанавливаемое соединение. Одновременно исходящая АТС передает вызывающему абоненту сообщение Q.931 CALL PROCEEDING.



[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [ 69 ] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103]

0.0011