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

Одно из применений ТСАР заключается в предоставлении механизма доступа удаленной АТС для инициализации услуги внутри другой АТС. Примером такого использования ТСАР является реализация услуги автоматического ответного вызова при занятости вызываемого абонента. Если абонент А набирает номер абонента Б, который в настоящее время занят другим разговором, то абонент А может набрать код услуги и повесить трубку. Когда вызываемый абонент Б освобождается от первого разговора и становится доступным для нового вызова, АТС абонента Б информирует об этом АТС абонента А с помощью посылки сообщения ТСАР. АТС абонента А посылает вызывной сигнал вызывающему абоненту. После того, как он снимает трубку, осуществляется обычная процедура установления соединения с АТС абонента Бис самим абонентом Б. В этом примере имеет место механизм посылки сообщений от АТС Б к АТС А, не связанный с конкретным установлением соединения.

В общем виде вариантами применения ТСАР являются ситуации, когда установление основного соединения наряду с сигнальным соединением невозможно или не требуется (например, при организации доступа к сетевым базам данных, при регистрации местонахождения абонента для связи с подвижными объектами, при обеспечении некоторых дополнительных услуг, при реализации функций эксплуатации, техобслуживания и управления сетью и др.).

Поясним эти ситуации. В ряде случаев для хранения определенной информации сети может быть использована база данных, хранящаяся в каком-либо выделенном узле сети. Действительно, если данная информация маршрутизации относится только к одному виду службы, то ее хранение в нескольких станциях сети вряд ли целесообразно. Когда требуется получить доступ к информации маршрутизации, между станцией и базой данных происходит обмен информацией, не относящейся к каналу. Этот обмен и обеспечивается подсистемой ТСАР.

Еще одно упомянутое выше использование ТСАР связано с необходимостью для различных видов служб наземной подвижной связи иметь информацию о местонахождении подвижного объекта и будет рассмотрено в параграфе 10.7.

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

Используется ТСАР и для развития инфраструктуры эксплуатации, техобслуживания и управления сетью. Эти функции, как правило, требуют передачи большого объема не относящейся к каналу информации между узлами. Подсистема эксплуатации и технического обслуживания (ОМАР) рассматривается в параграфе 10.9.

Применения ТСАР могут разделяться на те, которые требуют ответов в реальном масштабе времени, и те, которые не требуют оперативных ответов. Например, если какой-то АТС требуется получить доступ к сетевой базе данных для получения специализированной информации маршрутизации во время установления соединения, то реальный масштаб времени необходим. Причем существенна каждая миллисекунда, т.к. время передачи информации в ТСАР прибавляется ко времени ожидания ответа после набора номера вызывающим абонентом. С другой стороны, для применений в реальном масштабе времени обычно предусматривается передача небольшого количества данных. Например, базе данных передается номер вызываемого абонента, а от базы данных возвращается информация о маршрутизации. Все это требует небольшого объема данных.

В применениях ТСАР вне реального масштаба времени скорость передачи информации не является критическим фактором. Например, если требуется передача большого объема статистических данных от АТС к центру технической эксплуатации (ЦТЭ), то время передачи в секундах (или даже в минутах) не является критическим. Более важным в данном случае является надежность передачи информации.

Во всех известных сегодня вариантах применения ТСАР непосредственно пользуется услугами SCCP; а транспортный, сеансовый и представительский уровни модели OSI отсутствуют.

Протокол ТСАР состоит из двух подуровней: нижнего - подуровня транзакции (TSL) и верхнего - компонентного подуровня (CSL).

Подуровень транзакции управляет установлением и разъединением соединений и определяет три типа сообщения: начало, продолжение и конец. Сообщение начала инициирует транзакцию, а сообщение продолжения используется во время транзакции.

Подуровень компоненты управляет действиями на удаленном узле и возвращением результатов таких действий. С этой целью осуществляется обмен между соответствующими подуровнями двух узлов путем посылки и приема компонент. Компонента состоит из запроса выполнения операции или ответа на запрос. Например, если станция А приняла номер телефона от вызывающего абонента, который необходимо преобразовать в специализированные данные маршрутизации с помощью базы данных сети, то эта станция посылает компоненту базе данных, запрашивая выполнение преобразования номера. Параметр компоненты содержит этот номер телефона. По завершении преобразования в базе данных компонента возвращается на станцию А в качестве ответа на запрос. Ответ может быть успешным (в этом случае может посылаться компонента возвращения результата) или неуспешным (в этом случае посылается компонента возвращения ошибки). Компонента ответа содержит параметр, включающий в себя информацию маршрутизации.

Операции, запрашиваемые подуровнем компоненты, можно разделить на четыре категории, называемые классами, в соответствии с уровнем ответа, ожидаемого по завершении операции.

К классу 1 относятся операции, для которых как успешный, так и ошибочный результаты их выполнения сообщаются узлу, который инициировал запрос выполнения операции. Примером такого рода операции является случай, когда АТС запрашивает удаленную базу данных преобразовать телефонный номер в данные маршрутизации. В данном случае база данных обязана послать обратно на АТС сообщение либо об успешном завершении операции с указанием пересчитанного номера в качестве результата, либо о неудачном завершении операции с указанием причины отказа.

Для класса 2 сообщается только об отказах при завершении операции. Эта категория может использоваться, когда, например, необходимо проведение тестирования какой-то функции, и ответ нужен только при наличии неисправности, препятствующей завершению теста.

Операции класса 3 используются, когда необходимо сообщить только об успешных результатах. Они могут использоваться в том случае, когда сбой подозревается и вероятным исходом операции является отказ. Считается, что операция была неуспешна, если не было получено сообщения об успешном результате.

В случае, когда ни об успешном завершении, ни об отказе не надо сообщать, операция относится к классу 4. Например, если узел желает послать предупреждение о некоем событии нескольким другим узлам, то ответ или подтверждение не требуется.

Сообщения ТСАР состоят из элементов информации, каждый из которых состоит из трех полей, располагаемых в фиксированном порядке и аналогичных структуре «название, длина и информация», описанной для SCCP и ISUP в двух разделах 10.3 и 10.4. В рекомендациях ITU-T для ТСАР эти же поля называются тег, длина и содержимое (рис. 10.15).

Тег идентифицирует тип посылаемого информационного элемента и влияет на значение поля содержимого. Тег занимает 1 байт и кодируется следующим образом: значение класса занимает 2 бита, форма - 1 бит, а код тега занимает 5 бит.

сообщение ТСАР

Рис. 10.15. Структура элемента информации

Рис. 10.16. Элемент информации конструктора Класс тега может принимать следующие значения: 00 - универсальный, 01 - прикладной, 10 - контекстно-зависимый, 11 - частное использование. Универсальный тег 00 соответствует рекомендации Х.208 и используется, например, для Х.400. Прикладной тег 01 используется в рамках ОКС7. Если значение класса равно 10, то это подразумевает контекстнозависимый класс, где одни и те же компоненты в различных сообщениях могут быть интерпретированы по-разному, в зависимости от их использования внутри данного сообщения. Контекстно-зависимый класс применяется, когда компоненты являются частью последовательности компонентов. Это называется конструктором, подразумевая, что каждая компонента строится с помощью другой компоненты (см. рис. 10.16 из рекомендации р.733).

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

Форма представляет собой 1 бит, принимающий значение 0, если тег является примитивом, или значение 1, если тег представляет собой конструктор.

Код тега может занимать и большее число разрядов. Тогда он находится в следующем байте. Однако в подавляющем большинстве применений значение кода умещается в 5 разрядах в первом же байте.

Поле длины указывает размер поля содержимого.

Поле содержимого включает в себя информацию, передаваемую элементом. Поле содержимого состоит из серии информационных элементов порции транзакции (ТР1Еб), каждый из которых соответствует общему формату «тег, длина, содержимое». В случае, когда более чем один информационный элемент находится в поле содержимого, то и он использует ту же самую структуру и сам состоит из тега, длины и содержимого (рис.10.15).

Сообщение ТСАР состоит из двух частей. Первая часть, называемая порцией транзакций, содержит информацию, необходимую для идентификации природы транзакции. Эта часть транзакции является необходимым полем для всех сообщений ТСАР. Вторая часть рассматривается как компонентная часть и является элементом содержимого для различных применений. Содержимое может состоять и из единственной величины. В этом случае элемент информации называется примитивом, как уже упоминалось выше.

Один ТР1Е содержит компонентную часть и состоит из тега компонентной части, длины компонентной части и содержимого компонентной части. В расширенном варианте рекурсивного подхода содержимое компонентной части состоит из ряда элементов информации компоненты, в начале каждого из которых стоит тег типа компоненты и поле длины

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

Рекурсивное использование тега, длины, содержимого может увеличить служебную информацию сообщения. Например, в простых сообщениях некоторая часть информации, которая неявно присутствует в типе сообщения, должна быть выражена в явном виде для соответствия общей структуре сообщения. Тем не менее, этот метод является очень гибким, и это намного перевешивает недостатки подхода «тег, длина, содержимое» в применениях, не относящихся к каналу.

В подсистеме ТСАР имеется весьма ограниченный набор процедур, который подразделяется на процедуры подуровня компоненты и процедуры подуровня транзакции. Данный подход ограничения набора собственных процедур поддерживает независимость ТСАР от применений, а всевозможные дополнительные процедуры, которые необходимы для реализации различных прикладных услуг, специфицируются в соответствующих прикладных подсистемах (INAP, MAP, ОМАР и др.).

Процедуры подуровня компоненты ТСАР иллюстрируются примером на рис. 10.18.

Рис. 10.18. Пример многократного вызова процедуры

На этом рисунке узел А посылает компоненту вызова (1) к узлу Б, но узлу Б требуется больше информации для начала обработки компоненты. Тогда узел Б инициирует свою собственную компоненту вызова (2), запрашивая ответ от узла А в компоненте возвращения результата (2). Проанализировав результат, узел Б отвечает на первичный вызов компонентой возвращения результата. Это происходит, когда узел А является станцией, которой требуется трансляция телефонного номера в информацию маршрутизации из базы данных в узле Б. В данном случае базе данных требуется больше информации из узла А. Например для обеспечения соответствующей информации маршрутизации, может потребоваться номер вызывающего абонента. После поступления этой информации в базу данных первичный вызов может быть обработан, и информация маршрутизации поступает на станцию А в виде параметра в составе компоненты возвращения результата (последней).

Спецификации ТСАР включают ряд процедур для использования в стандартных условиях. В частности, если компонента вызова получена с синтаксической ошибкой, то в обратную сторону посылается компонента отказа с указанием причины неисправности.

Примером процедур подуровня транзакции в структурированном диалоге может являться следующая ситуация. Станция А инициирует начало структурированного диалога посылкой сообщения начала. Идентификатор исходящей транзакции (ОТШ), выбираемый станцией А и включаемый в сообщение начала, обозначен через X. Станция Б анализирует сообщение начала и соглашается установить диалог. Станция Б возвращает сообщение продолжения для подтверждения этого решения. Эта же станция выбирает ОТШ со значением У для его включения в сообщение продолжения. Поле идентификатора входящей транзакции (БМБ) содержит идентификатор X, соответствующий номеру, выбранному станцией А. Получив сообщение продолжения от АТС Б станция А анализирует информацию и посылает сообщение продолжения станции Б. В этом случае ОТШ имеет значение X, а БТШ - значение У. После приема и анализа сообщения продолжения от АТС А станция Б определяет, что диалог может быть завершен и возвращает сообщение конца. В сообщении конца отсутствует ОТШ, а БТШ равен X.

В этом примере станция Б инициировала окончание диалога, но данную функцию так же могла бы выполнить и станция А. Случай, когда любая из двух АТС инициирует сообщение конца, называется базовым методом окончания диалога. Существует другой метод окончания диалога, называемый подготовленным. Обычное применение подготовленного конца - случай, когда станция нуждается в информации из базы данных, но не знает, какую базу данных запросить. В этом случае запрос циркулярно передается нескольким базам данных с ожиданием, что только одна из них ответит положительно. Чтобы избежать необходимости ожидания отрицательного ответа от всех баз данных, кроме одной, диалог считается законченным, если не получено положительного ответа. Диалог продолжается далее только между АТС и базой данных, ответившей положительно.

⇐Pty | Сигнализация в сетях связи | Подсистема интеллектуальной сети шар⇒