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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 10.17. Принцип организации формата сообщения ТСАР

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

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

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

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

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

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

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

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

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

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

10.6. Подсистема интеллектуальной сети шар

Революционная концепция конструирования телекоммуникационных услуг, созданная в 1984 г. в Bell Laboratory и получившая наименование интеллектуальной сети (IN), строится также исключительно на базе системы общеканальной сигнализации ОКС7.

Действительно, согласно концепции IN для ввода новой телекоммуни­кационной услуги нужно не вносить изменения в уже существующие коммутационные узлы и станции, а построить новый узел, поддерживающий функции этой новой услуги, которая с помощью ОКС7 будет доступна всем абонентам этого нового и ранее установленных узлов.

Сетевые функции IN могут находиться в различных узлах: функции коммутации услуги SSF (Service Switching Function) будут сосредоточе­ны в узле коммутации услуги SSP (Service Switching Point); функции управления услугой SCF (Service Control Function) сосредотачиваются в узле управления услугой SCP (Service Control Point); функции данных услуги SDF (Service Data Function) будут сосредоточены в узле данных услуги SDP (Service Data Point). Так как все эти функции и узлы могут быть разделены между собой как логически, так и физически, их взаимодействие осуществляется по специальному протоколу INAP.

Спецификации этого прикладного протокола интеллектуальной сети INAP приведены в рекомендации Q.1218. Российская национальная версия протокола INAP-R построена в соответствии со стандартом ETS 300 374-1: 1994 г. Европейского института стандартизации (ETSI). Именно из этого стандарта взят приведенный на рис. 10.19 пример взаимодействия двух географически разделенных функций INAP.

Имеются два основных варианта архитектуры INAP. Первый предназначен для множественного взаимодействия нескольких прикладных процессов со взаимной координацией, а второй вариант ориентирован на взаимодействие одного прикладного процесса с другим.

В случае единичного взаимодействия координационные функции при использовании прикладных элементов ASE выполняются функцией SACF на основании полученных примитивов. SAO представляет совокупность SACF с набором прикладных элементов ASE, которые используются при одиночном взаимодействии между парой физических элементов.

В случае множественного взаимодействия функция MACF выполня­ет координационные функции среди нескольких SAO, каждый из которых взаимодействует с SAO, находящимся в удаленном физическом узле.

В рекомендациях ITU-T и стандартах ETSI спецификации 1NAP приводятся на языке ASN. 1, рассмотренном в главе 2. INAP является пользовательским протоколом ROSE, о чем также упоминалось в главе 2.

INAP поддерживает любое распределение функциональных элементов по физическим узлам и рассчитан на возможность максимального распределения, т.е. один функциональный элемент в одном узле.

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

Рис. 10.19. Поддержка взаимодействия географически распределенных функций SCF и SDF протокола INAP

10.7. Подсистемы мобильной связи map и bssap стандарта gsm

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

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

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

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

К основным процедурам MAP относятся регистрация местоположения абонента для сохранения возможности осуществления исходящих и приема входящих вызовов в пределах всей сети; перерегистрация и стирание предыдущей информации о местоположении абонента; дополнительные виды обслуживания; изменение абонентских данных как в HER, так и в VLR; передача информации о тарификации и др.

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

Сценарии и SDL-диаграммы процедур MAP читатель сможет найти в документе 1-ETS 300 044 Европейского института по стандартизации в телекоммуникации ETS1, неоднократно упомянутого в книге.

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

Рис. 10.20. Процедура хендовера между BTS и между MSC

или иной мобильный абонент. Эта запись обновляется каждые несколько минут.

Сигнализация ОКС7 используется для выполнения этого обновления, то есть для получения сообщения в базу данных HLR из базы данных VLR (visitor location register) коммутационного узла, в котором временно находится мобильный абонент. Когда вызываемому абоненту поступает входящий вызов, основной регистр HLR определяет, каким образом можно соединиться с абонентом в зависимости от его текущего местоположения. По мере перемещения абонента из одной зоны в другую содержимое основного регистра HLR постоянно обновляется с помощью сообщений ОКС7. Такой механизм позволяет мобильному абоненту абсолютно свободное передвижение в пределах всей сети без риска потерять входящие вызовы, как это показано на рис. 10.21.

Помимо ТС АР и МТР протокол MAP также использует подсистему управления соединениями сигнализации SCCP, причем только не ориентированные на соединение классы услуг (классы 0 и 1).

Другая подсистема BSSAP представляет собой протокол для взаимосвязи станций центров коммутации MSC с контроллерами базовых станций BSC. На рис. 10.22 представлена структура BSSAP, состоящая из трех частей: прикладной части управления системой базовых станций BSSMAP (Base Station System Management Application Pail), прикладной части для прямой передачи DTAP (Direct Transfer Application Part) и части с функцией разделения сообщений. BSSAP пользуется услугами МТР и SCCP обеих категорий: ориентированной и не ориентированной на соединение.