Подсистема сетевых услуг

В данном разделе описана часть стека протоколов SS7, соответствующая трем нижним уровням эталонной модели OSI — физическому, канальному и сетевому. В архитектуре SS7 она называется подсистемой сетевых услуг (Network Services Part, NSP) и включает подсистему передачи сообщений (Message Transfer Part, MTP) и подсистему управления соединением сигнализации (Signaling Connection Control Part, SCCP). Подсистемы MTP, SCCP и другие компоненты стека протоколов SS7 представлены на рис. 8.

Рис. 8. Архитектура стека протоколов SS7

Подсистема передачи сообщений состоит из трех уровней: звена данных сигнализации, звена сигнализации и функций сети сигнализации. Подсистема SCCP по отношению к MTP выступает в роли пользователя. Следовательно, SCCP является четвертым уровнем стека протоколов SS7. Подсистема MTP обеспечивает функции передачи сообщений без установления соединения (connectionless), а SCCP —дополнительные функции, необходимые для реализации услуг сети как без установления, так и с установлением соединения (connection-oriented). Таким образом, подсистема сетевых услуг NSP предназначена для надежной передачи сообщений между приложениями SS7 и всеми типами подсистем пользователя.

Подсистемы передачи сообщений MTP

Рис. 9. Функциональная структура MTP

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

Функции звена данных сигнализации (MTP1). Звено данных сигнализации (Signaling Data Link, SDL) — это двунаправленный путь передачи, который состоит из двух каналов, обеспечивающих одновременный транспорт в противоположных направлениях с одинаковой скоростью. Канал SDL полностью соответствует определению физического уровня модели OSI. Цифровое звено данных сигнализации включает в себя цифровые каналы и оконечное оборудование, формирующее интерфейс с сигнальными терминалами. Аналоговый вариант содержит аналоговые каналы передачи и модемы. Каналы передачи могут быть наземными или спутниковыми.

Для цифрового звена SDL скорость передачи равна 64 кбит/с согласно рекомендациям Международного союза электросвязи (ITU-T) и 56 кбит/с в соответствии с предложениями Американского национального института по стандартизации (ANSI). Скорость 56 кбит/с используется с учетом параметров задержек сигнальных сообщений в подсистемах пользователя. Для приложений управления телефонным вызовом допустима минимальная скорость 4,8 кбит/с.

Функции звена сигнализации (MTP2). Эти функции соответствуют второму уровню звена данных модели OSI. Вместе со звеном данных сигнализации они обеспечивают надежную передачу сигнальных сообщений (в виде сигнальных единиц переменной длины) между двумя непосредственно соединенными пунктами сигнализации.

Функции MTP2 и протоколы для цифровых звеньев других типов, например HDLC (High-level Data Link Control), имеют как общие черты, так и различия. Последние связаны с необходимостью быстро реагировать на сбои в сети. Для обозначения начала и конца сигнальной единицы существует стандартный флаг 01111110.

Обнаружить ошибки позволяют 16 проверочных бит, так называемая контрольная сумма проверки циклической избыточности (Cyclic Redundancy Check, CRC). При отсутствии сигнального трафика в SS7 происходит передача заполняющих сигнальных единиц, тогда как в других протоколах — передача последовательности флагов. В SS7 это дает возможность реализовать мониторинг ошибок с целью быстрого обнаружения поврежденных звеньев сигнализации и их удаления из процесса передачи.

Исправление ошибок. Определенные в SS7 базовый метод защиты от ошибок (Basic Error Control Method, BECM) и метод принудительного циклического повторения (Preventive Cyclic Retransmission, PCR) выявляют ошибки во всех трех типах сигнальных единиц — MSU, FISU и LSSU, процедуры же исправления ошибок выполняются только для MSU и LSSU. Благодаря этим методам исправления ошибок обеспечивается передача сигнальных единиц в правильной последовательности и без дублирования.

В целях исправления ошибок в базовом методе используются положительные (positive ACKnowledgement, ACK) и отрицательные (Negative ACKnowledgement, NACK) подтверждения. При поступлении сигнала NАСК исправление ошибок осуществляется путем повторной пересылки всех MSU, переданных к моменту получения этого сигнала, вслед за последней MSU, на которую получено положительное подтверждение. Такое подтверждение означает правильность приема MSU и уведомляет оконечное оборудование о том, что сообщения из буфера повторной передачи можно удалить. Для контроля передачи сигнальной единицы в правильной последовательности служат входящие в состав SU прямой и обратный порядковые номера FSN и BSN, а также прямой и обратный биты индикации FIB и BIB (см. рис. 6 в первой части статьи). Длина каждого порядкового номера — 7 бит, следовательно, максимальное число сообщений, которые могут быть отправлены без получения положительного подтверждения, равно 127.

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

Если количество неподтвержденных значащих сигнальных единиц (сообщений или байтов) превышает некоторую предельную величину, это говорит о том, что нормальные процедуры циклического повторения не обеспечивают исправления ошибок. Такая ситуация может возникнуть при высокой интенсивности трафика, из-за которой существенно снижается скорость повторной передачи сообщений. В этом случае активизируется процедура принудительного циклического повторения: передача новых MSU прекращается и начинается повторная передача неподтвержденных значащих сигнальных единиц. Эта процедура продолжается до тех пор, пока число неподтвержденных сообщений не окажется ниже указанных предельных значений.

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

Мониторинг ошибок. В SS7 применяются два типа мониторов интенсивности ошибок звена сигнализации. Монитор интенсивности ошибок в сигнальных единицах (Signal Unit Error Rate Monitor, SUERM) функционирует в действующем звене сигнализации и поддерживает критерии отключения звена при высокой интенсивности ошибок. Монитор интенсивности ошибок фазирования (Alignment Error Rate Monitor, AERM) используется на стадии выполнения звеном сигнализации процедур начального фазирования и обеспечивает отключение звена в случае высокой интенсивности ошибок во время начального фазирования.

Управление потоком. Процедуры управления потоком инициализируются при обнаружении перегрузки на приемном конце звена сигнализации. Приемный конец уведомляет передающий конец о перегрузке путем отправки сигнальных единиц состояния звена LSSU с индикацией состояния «занято» и задержкой подтверждений для всех поступающих сигнальных единиц. Из-за отсутствия подтверждений передающий конец не отключает звено сигнализации. Однако если состояние перегрузки продолжается слишком долго (более 6 с), то передающий конец считает такое звено поврежденным.

Уровень MTP2 передает индикатор состояния «процессор отключен» (Signaling Indication Processor Outage, SIPO) как при непосредственном обнаружении сбоев на следующем уровне (MTP3), так и при поступлении соответствующего индикатора от MTP3. При получении индикатора SIPO удаленный конец блокирует передачу сигнальных сообщений к МТР3 и выше. Индикация состояния «процессор отключен» передается от удаленного конца МТР2 к МТР3 в составе сигнальных единиц LSSU. Уровень МТР3 производит маршрутизацию трафика в соответствии с процедурами управления сетью, описанными ниже.

Рис. 10. Функции сети сигнализации

Функции сети сигнализации (МТР3). Функции сети сигнализации соответствуют сетевому уровню модели OSI и отвечают за передачу сообщений между пунктами сигнализации. Они подразделяются на две основные категории (рис. 10): обработка сигнальных сообщений и управление сетью сигнализации.

Обработка сигнальных сообщений состоит из функций маршрутизации, распознавания (сортировки) и распределения сообщений. Эти функции выполняются в каждом пункте сигнализации в соответствии с меткой маршрутизации и полями байта сигнальной информации SIO отдельных сигнальных единиц. Метка маршрутизации состоит из кода пункта назначения (Destination Point Code, DPC), кода исходящего пункта (Origination Point Code, OPC) и поля селекции звена сигнализации (Signaling Link Selection field, SLS), как показано на рис. 6 первой части статьи. Метка маршрутизации расположена в начале поля сигнальной информации SIF и является общей для каждого из пользователей МТР.

В стандарте ITU длина каждого из полей DPC и OPC составляет 14 бит, а поля SLS — 4 бита, в стандарте ANSI — соответственно 24 бита (по 8 бит на индикатор сети, номер кластера и номер элемента) и 5 бит (3 бита в метке маршрутизации являются резервными).

Звено сигнализации для передачи сообщения, поступившего от пользователя МТР2, выбирает функция маршрутизации сообщений. При приеме сигнальной единицы от уровня МТР2 функция сортировки сообщений анализирует код пункта назначения DPC с целью определить, предназначается ли принятая сигнальная единица данному пункту сигнализации или адресована другому. Если пункт, в котором осуществляется анализ DPC, является транзитным (STP), производится маршрутизация сообщения. Если же сообщение адресовано принимающему пункту сигнализации, то активизируется либо функция распределения сообщений, которая доставляет сообщение соответствующему пользователю МТР, либо функция подсистемы МТР3, анализирующая поле индикатора услуги SI в составе байта служебной информации SIO. Далее на основе анализа полей DPC и SLS выполняется маршрутизация сообщений.

Обычно маршрутизация сообщения к требуемому пункту назначения осуществляется по нескольким звеньям сигнализации. Идентификация конкретного звена определяется полем селекции звена сигнализации. Эта процедура, называемая разделением сигнальной нагрузки (Load Sharing) по звеньям сигнализации, принадлежащим и/или не принадлежащим к одному пучку, обеспечивает равномерное распределение сигнальной нагрузки по всем звеньям сигнализации пучка. Сообщения, которые должны передаваться в определенной последовательности, имеют одинаковое поле SLS и направляются по одному и тому же пути.

Управление сетью сигнализации. Функции этой группы предназначены для изменения конфигурации сети сигнализации в случае отказов звеньев или пунктов сигнализации и управления трафиком при их перегрузке либо блокировке. В случае сбоя реконфигурация сети предотвращает потери, дублирование и нарушение исходной последовательности сигнальных сообщений, а также чрезмерный рост задержек передачи. Управление сетью сигнализации (см. рис. 10) состоит из функций управления сигнальным трафиком, маршрутами сигнализации и звеньями сигнализации. Эти функции активизируются при изменении статуса звена сигнализации, сигнального маршрута или пункта сигнализации.

1. Функция управления сигнальным трафиком используется для перенаправления сигнального трафика с одних звеньев сигнализации или маршрутов на другие (альтернативные), а также для снижения уровня сигнального трафика при перегрузке. В случае недоступности звена сигнализации запускается процедура перехода на резерв (change-over), которая перенаправляет сигнальный трафик в одно или большее число альтернативных звеньев. После того как функционирование звена сигнализации нормализовалось, процедура восстановления исходного состояния (change back) переводит сигнальный трафик в первоначальное звено.

Процедуры вынужденной и управляемой повторной маршрутизации (forced rerouting и controlled rerouting соответственно) используются для перевода трафика с недоступных маршрутов на альтернативные и для последующего возврата к исходным маршрутам. При управляемой повторной маршрутизации перенаправление трафика на альтернативный маршрут выполняется также в случае ограниченного доступа к исходному маршруту. Процедура перезапуска пункта сигнализации производит корректировку состояния сетевого маршрута и процесса управления в случае возврата сигнального трафика в ставший доступным пункт сигнализации.

2. Функция управления маршрутами сигнализации служит для распределения информации о состоянии сети сигнализации с целью блокировки или разблокировки маршрутов и состоит из нескольких процедур.

Процедура управляемой передачи (Transfer-controlled Procedure) выполняется в транзитном пункте сигнализации при перегрузке звена сигнализации. В результате для каждого принятого сообщения, имеющего меньший приоритет перегрузки, чем уровень перегрузки в звене сигнализации, в исходящий пункт передается управляющее сообщение. При этом транспортировка сообщений, приоритет перегрузки которых не превышает уровень перегрузки в звене, останавливается. В стандартах ANSI используются четыре приоритета перегрузки, в стандартах ITU-T — только один.

Процедура запрещения передачи (Transfer-prohibited Procedure) осуществляется в STP для информирования соседних пунктов сигнализации о том, что маршрут следования сообщения к конкретному пункту назначения не должен проходить через этот STP. Указанная процедура может активироваться, например, при отсутствии доступных маршрутов в определенном направлении.

Процедура ограничения передачи (Transfer-restricted Procedure) выполняется в STP для сообщения соседним пунктам сигнализации о транспортировке сигнального трафика с данным кодом пункта назначения DPC по маршрутам, не проходящим через этот STP.

Процедура разрешения передачи (Transfer-allowed Procedure) сообщает соседним пунктам сигнализации о снятии состояния запрета на маршрутизацию сообщений через данный STP.

Наконец, процедуры тестирования пучка маршрутов выполняются в STP с целью проверки, может ли сигнальный трафик маршрутизироваться к конкретному пункту назначения через этот STP. В стандарте ANSI процедуры тестирования служат для корректировки состояния перегрузки, связанного с конкретным маршрутом.

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

Подсистема управления звеном сигнализации SCCP

Эта подсистема предоставляет дополнительные, по отношению к МТР, функции для реализации услуг сетевого уровня модели OSI. Возможности подсистемы МТР ограничены передачей сигнальных сообщений к сетевым узлам и использованием 4-битного поля индикатора услуги SI для распределения сообщений в пункте сигнализации. Подсистема SCCP позволяет осуществлять адресацию сообщений на основе поля кода пункта назначения DPC и номеров подсистем (Subsystem Numbers, SSN). Номер подсистемы —это локальная адресная информация, которую SCCP использует для идентификации своих пользователей в узле. Подсистема SCCP дополняет МТР возможностью адресации сообщений с глобальным наименованием (Global Title, GT). Она осуществляет трансляцию глобального наименования (Global Title Translation, GTT) в поля DPC и SSN. Функция GТT может выполняться как в исходящем, так и в других пунктах сигнализации сети.

Подсистема SCCP предоставляет четыре класса услуг:
  • 0 — основной класс услуг, не ориентированных на соединение;
  • 1 — класс услуг с контролем последовательности доставки сообщений (подсистемой МТР), не ориентированных на соединение;
  • 2 — основной класс услуг, ориентированных на соединение;
  • 3 — класс услуг, ориентированных на соединение, с управлением потоками.

В классе 0 более высокие уровни передают подсистеме SCCP исходящего пункта блок данных услуги сети (Network Service Data Unit, NSDU). В подсистему SCCP пункта назначения он поступает в составе поля данных сообщения (Unit Data, UDT) и далее направляется к более высоким уровням. Блоки NSDU передаются подсистемой МТР от исходящей к приемной подсистеме SCCP независимо а, значит, могут поступать в пункт назначения в последовательности, отличной от исходной. Поэтому класс 0 называется классом услуг, не ориентированных на соединение.

Класс 1 в дополнение к функциям класса 0 позволяет более высоким уровням указывать подсистеме SCCP, какой из NSDU-потоков должен быть доставлен в узел назначения в заданной последовательности.

В классе 2 установление временного или постоянного сигнального соединения (например, виртуального канала в сети) выполняется при передаче NSDU-потоков в двух направлениях. Для обеспечения правильной последовательности сообщения, относящиеся к одному сигнальному соединению, имеют одинаковое поле селекции звена сигнализации SLS. Если длина блока NSDU превышает 255 байт, то в исходящем узле выполняется его сегментация, затем сегменты NSDU передаются в составе поля данных сообщения UDT в пункт назначения, а там подсистемой SCCP собираются в исходный блок NSDU.

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

Рис. 11. Функциональная структура SCCP

Подсистема SCCP, структура которой показана на рис. 11, состоит из четырех функциональных блоков. Блок управления SCCP с установлением соединения (SCCP Connection-Oriented Control block, SCOC) управляет установлением и разъединением сигнальных соединений и служит для передачи данных по этим соединениям. Блок управления SCCP без установления соединения (SCCP Connectionless Control block, SCLC) реализует передачу блоков данных без установления соединения. Блок управления SCCP (SCCP Management block, SCM) обеспечивает работу сети в случаях неисправности или перегрузки подсистемы — пользователя SCCP, либо сигнального маршрута. Блок маршрутизации SCCP (SCCP Routing block, SCR) принимает сообщения от МТР или иных функциональных блоков SCCP и выполняет их маршрутизацию — направляет сообщение в МТР для передачи другому пункту сети либо передает его другим функциональным блокам SCCP.

Подсистемы пользователя

В этом разделе определены две основные подсистемы пользователя, использующие услуги MTP и SCCP: подсистема пользователя ISUP и прикладная подсистема возможностей транзакций (Transaction Capabilities Application Part, TCAP). Подсистема телефонного пользователя (TUP) и подсистема пользователя данных (DUP) здесь не рассматриваются, поскольку их функции реализует ISUP.

Подсистема ISUP

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

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

Подсистема ISUP была разработана 11-й исследовательской комиссией ITU-T (Study Group XI, SGXI) по запросу SGXVIII для объединения функций TUP и DUP в целях предоставления услуг ISDN по интеграции голоса и данных. В дальнейшем эта комиссия дополнила протокол ISUP рядом функций, нацеленных на поддержку широкого диапазона услуг, например относящихся к взаимодействию с протоколом сигнализации в D-канале. Первая версия ISUP появилась в 1984 г. («Красная книга») в составе рекомендаций Q.761-Q.766. Через четыре года была опубликована следующая версия («Голубая книга») с дополнительными услугами ISDN, представленными в рекомендации Q.730. Наконец, в 1994 г. состоялось принятие стандарта («Белая книга»), незначительно отличающегося от предыдущих версий.

Подсистема ISUP поддерживает два класса услуг — базовый и дополнительный, используя как возможности МТР для надежной передачи сигнальных сообщений между станциями, так и услуги SCCP для сигнализации «из конца — в конец» (см. рис. 8).

Длина сообщения ISUP (рис. 12), включая заголовки подсистемы МТР3, является переменной; ее максимальное значение равно 272 байтам. Каждое сообщение имеет метку маршрутизации, идентифицирующую исходящий пункт и пункт назначения, код идентификации канала (Circuit Identification Code, CIC) и код типа сообщения, однозначно определяющий функциональное назначение и структуру каждого сообщения ISUP. Тип сообщения задает позицию, длину и порядок расположения параметров в обязательной (фиксированной) части сообщения. За этой частью следуют указатели на обязательные параметры фиксированной длины и необязательные параметры переменной длины. Первые определяются индикатором длины и содержимым параметра, а вторые — еще и именем параметра.

Рис. 13. Пример установления

и разъединения

соединения в ISUP

Базовый класс услуг подсистемы ISUP отвечает за управление установлением соединений между оконечными коммутационными станциями в сетях с коммутацией каналов. Штатная процедура установления и разъединения базового соединения ISDN между двумя станциями изображена на рис. 13. Сигнализация от абонента к станции осуществляется по D-каналу с применением протокола DSS1 (Digital Subscriber Signaling System No.1, Q.931).

В данном примере вызывающий абонент А набирает номер и направляет вызов к вызываемому абоненту В. При этом в сети связи и сети сигнализации происходят следующие действия.

1. Станция 1 анализирует набранный номер и определяет, что вызов должен быть направлен к станции 2.

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

3. Пункт сигнализации А на станции 1 выбирает одно из звеньев сигнализации (например, AC) и передает по нему сообщение IAM для маршрутизации к станции 2.

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

5. Пункт сигнализации В на станции 2 принимает сообщение, анализирует его и определяет, что данное сообщение относится к вызываемому абоненту В, номер которого находится в состоянии «свободен».

6. Пункт сигнализации В формирует сообщение о принятии полного адреса АСМ, которое означает, что сообщение IAM достигло пункта назначения без ошибок. В сообщении содержатся код пункта назначения А, код исходящего пункта В и идентификатор выбранного разговорного тракта.

7. Пункт сигнализации В выбирает одно из звеньев сигнализации (например, ВD) и передает по нему сообщение ACM для маршрутизации к станции 1. Одновременно станция 2 проключает разговорный тракт в обратном направлении к станции 1, посылает по этому тракту тональный сигнал и, наконец, направляет звонок по линии к вызываемому абоненту В.

8. Транзитный пункт сигнализации D принимает сообщение, анализирует его метку маршрутизации и определяет, что сообщение должно быть направлено в пункт сигнализации А на станции 1. Сообщение передается по звену DA.

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

10. В момент снятия трубки абонентом В станция 2 формирует сообщение «ответ абонента» ANC. В нем определяются код пункта назначения А, код исходящего пункта В, выбранный разговорный тракт и другая служебная информация.

11. Станция 2 выбирает для передачи сообщения ANС то же звено сигнализации BD, что и для передачи сообщения АСМ. К этому моменту разговорный тракт подключен к абонентским линиям в обоих направлениях.

12. Транзитный пункт сигнализации D принимает сообщение, анализирует его метку маршрутизации и определяет, что сообщение должно быть маршрутизировано к пункту сигнализации А на станции 1. Сообщение передается по звену DA.

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

14. Если вызывающий абонент кладет трубку первым, то коммутационная станция 1 генерирует сообщение REL, адресованное станции 2, об освобождении разговорного тракта, ассоциированного с данным вызовом. Пункт сигнализации А посылает это сообщение по звену сигнализации АС.

15. Транзитный пункт сигнализации C принимает сообщение, анализирует его метку маршрутизации и определяет, что сообщение должно быть направлено в пункт сигнализации В на станции 2. Сообщение передается по звену СВ.

16. Станция 2 принимает сообщение REL, отключает разговорный тракт от линии вызываемого абонента В, возвращает разговорный тракт в состояние «свободен», генерирует сообщение RLC об освобождении тракта со своей стороны и посылает его по звену сигнализации BD.

17. Транзитный пункт сигнализации D принимает сообщение, анализирует его метку маршрутизации и определяет, что сообщение должно быть передано в пункт сигнализации А на станции 1. Сообщение передается по звену DA.

18. Получив сообщение RLC, станция 1 возвращает разговорный тракт в состояние «свободен».

Прикладная подсистема возможностей транзакций

Термин «возможности транзакций» охватывает множество протоколов и функций, которые используются распределенными сетевыми приложениями для взаимодействия друг с другом. В контексте системы сигнализации №7 возможности транзакций относятся к протоколам прикладного уровня модели OSI в совокупности с услугами уровней транспортного, сеансового, представлений, а также с их протоколами. Для всех приложений SS7 подсистема TCAP обращается непосредственно к услугам SCCP; упомянутые выше уровни модели OSI отсутствуют (см. рис. 8).

Для систем, функционирующих без установления соединения, TCAP обеспечивает набор механизмов, которые могут использоваться приложениями одного узла для запуска процедуры другого узла сети и обмена результатами ее вызова. С этой целью в состав TCAP включены протоколы и услуги для взаимодействия подсистем на удаленных объектах. Протокол TCAP является аналогом протокола ROSE (Remote Operation Service Element), специфицированного в рекомендациях X.219 и X.229.

Распределенные сетевые приложения, обращающиеся к TCAP, должны оставаться резидентными на станциях и серверах баз данных, которые указанные приложения используют. Основное назначение TCAP при этом — вызов удаленных процедур для обеспечения услуг интеллектуальной сети (IN), например услуги бесплатного вызова (Freephone).

Рис. 14. Структура

прикладного уровня SS7

Структура прикладного уровня, включая подсистему TCAP, показана на рис. 14. Пользователь TC, называемый прикладным элементом услуги (Application Service Element, ASE), предоставляет специфическую информацию, необходимую каждому приложению, например, для запроса удаленных баз данных. Подсистема TCAP включает механизмы выполнения удаленных процедур для всех приложений.

Протокол TCAP состоит из двух подуровней — подуровня компонентов (Component Sublayer, CSL) и подуровня транзакций (Transaction Sublayer, TSL). Подуровень CSL обеспечивает обмен компонентами между пользователями TC, которые являются эквивалентом блока данных протокола (Protocol Data Unit, PDU) в ROSE. Компоненты состоят из запросов на выполнение операции на удаленном конце, т.е. активизации некоторого процесса, или данных, поступающих в ответ на запрос. Подуровень транзакции TSL контролирует обмен сообщениями между пользователями TC в целях установления диалога (транзакции) и управления им.

Подуровень транзакций. Под транзакцией понимается полное выполнение операции, например обмен запросами и ответами между двумя пользователями TC. Подуровень транзакций отвечает за управление подобным процессом. Между подуровнями TSL существуют два типа диалога — неструктурированный и структурированный. Неструктурированный диалог обеспечивает передачу между пользователями TC одного или большего числа компонентов, не требующих ответа. Компоненты диалога поступают к подуровню TSL от пользователя TC через подуровень CSL, а затем в виде однонаправленных сообщений (Unidirectional Message) передаются в удаленный подуровень TSL. В случае неструктурированного диалога явная связь между подуровнями TSL не устанавливается.

В структурированном диалоге пользователь TC передает подуровню CSL примитив начала диалога TC-BEGIN, содержащий параметр идентификации диалога ID. Все компоненты, передаваемые пользователем TC в рамках одного диалога, имеют одинаковый параметр ID. Подуровень CSL преобразует примитив TC-BEGIN пользователя TC в примитив TR-BEGIN сообщения транзакции (который также содержит ID) и передает его подуровню TSL. Для продолжения и завершения диалога используются примитивы продолжение диалога (TC-CONTINUE), конец диалога (TC-END), прерывание диалога пользователем (TC-U-ABORT) и прерывание диалога подсистемой (TC-P-ABORT), которые преобразуются в примитивы TR-CONTINUE, TR-END, TR-U-ABORT, TR-P-ABORT соответственно. Подуровень TSL выполняет управление каждой транзакцией, используя идентификатор ID, группирует компоненты одной и той же транзакции в соответствующие сообщения BEGIN, CONTINUE, END, ABORT и передает их подуровню TSL удаленного конца соединения (рис. 14, 15).

Таким образом, назначение подуровня TSL — установить соединение между двумя пользователями TC, по которому они смогут обмениваться компонентами.

Подуровень компонентов. Компонент данного подуровня состоит либо из запроса на выполнение удаленной операции, либо из ответа. На каждый запрос может быть передан только один ответ. При необходимости производится сегментация запроса. Исходящий пользователь TC может послать подуровню CSL несколько компонентов для их транспортировки в удаленный подуровень CSL в составе одного сообщения. На принимающем конце компоненты разбираются и передаются пользователю TC по одному в нужном порядке. Последовательные компоненты, которыми обмениваются пользователи TC для выполнения приложения, образуют диалог. Двум пользователям TC подуровень CSL позволяет параллельно установить несколько структурированных или неструктурированных диалогов.

Рис. 15. Сообщения TCAP

При структурированном диалоге CSL предоставляет функцию, ассоциирующую ответы с операциями (запросами пользователей ТС к удаленному концу соединения), а также средства обработки аварийных ситуаций. Вызов операции определяется уникальным идентификатором компонента ID. Таким образом, одновременно может использоваться несколько вызовов одной и той же удаленной операции. Значение параметра ID однозначно идентифицирует вызов операции и возвращается в ответе на эту операцию. Для подуровня CSL определены четыре класса удаленных операций. К классу 1 относятся операции, результат выполнения которых (как успешный, так и ошибочный) сообщается узлу. Для класса 2 подтверждаются только ошибки выполнения, а для класса 3 — только успешные результаты. Наконец, к классу 4 относятся операции, которые не требуют подтверждения ни об успешном завершении, ни об отказе. В состав ответов на операцию могут входить компоненты возврат результата (последний) — Return Result (Last), возврат ошибки (Return Error) или отказ (Reject), зависящие, соответственно, от результата, ошибки выполнения или наличия синтаксической ошибки в запросе, которая выявилась в ходе выполнения операции (см. рис. 15). Из-за ограниченности размера сигнального сообщения сегментация успешного результата может производиться при помощи компонента возврата промежуточного результата (Return Result-Not-Last, RR-NL). Кроме того, до передачи ответа на исходящую операцию можно инициировать любое количество связанных операций.

Рис. 16. Структура

сообщения TCAP

Структура сообщений ТСАР. Структура сообщения ТСАР показана на рис. 16. Согласно рекомендации X.209, сообщение ТСАР состоит из информационных элементов, включающих метку (tag), параметр длины (length) и содержание (value). Порция транзакции (Transaction Portion) по метке типа сообщения определяет его как однонаправленное сообщение либо как сообщение BEGIN, CONTINUE, END или ABORT. Для всех типов сообщений (за исключением однонаправленного) порция транзакции расположена после метки, параметра длины и идентификатора ID. Порция компонента (Component Portion) включает метку и длину порции компонента, следующие за отдельными компонентами. В состав каждого компонента входят метка типа, длина компонента и информационный элемент, задающий обязательные параметры данного компонента. Метка типа определяет принадлежность компонента к категории INVOKE, RETURN RESULT, RETURN ERROR или REJECT.

Рис. 17. Пример выполнения процедур услуги

интеллектуальной сети Freephone подсистемой ТСАР

Рис. 17 иллюстрирует процедуру обмена сообщениями ТСАР между коммутационной станцией, получившей вызов Freephone (услуга интеллектуальной сети), и сетевой базой данных, содержащей информацию о маршрутизации вызова. Для трансляции номера БД запрашивает у станции дополнительную информацию, например номер вызывающего абонента. С целью выполнения процедуры подсистема TCAP пункта сигнализации станции передает сообщение BEGIN, которое инициализирует структурированный диалог с подсистемой TCAP узла базы данных. При обработке сообщения BEGIN в узле БД запускается процесс с параметром ID#l, запрашивающий трансляцию маршрутного номера для услуги Freephone. Набранный номер является параметром компонента INVOKE. В рамках этого структурированного диалога узел базы данных передает в обратном направлении сообщение о продолжении диалога CONTINUE для вызова операции, которая перешлет дополнительную информацию о вызывающей стороне. Сообщение CONTINUE имеет идентификатор ID#2 и связано с сообщением, помеченным ID#l. Станция осуществляет необходимые действия и передает БД сообщение CONTINUE, в котором дополнительные данные содержатся в составе компонента RETURN RESULT с идентификатором ID#2. После приема и обработки этого сообщения база данных передает станции сообщение END о завершении диалога. Сообщение END включает в себя компонент RETURN RESULT с идентификатором ID#1; оттранслированный номер присутствует в нем в виде параметра.

Заключение

Основное назначение данной работы — ввести читателя в круг базовых понятий системы сигнализации № 7 и на основе простейших примеров осветить услуги сетей связи, построенных на базе SS7. Описание архитектуры сети SS7 и подходов к ее проектированию в русcкоязычных источниках практически отсутствует. Ощущается нехватка систематизированного изложения основных концепций, используемых при построении интеллектуальной сети и сетей сотовой подвижной связи, хотя опубликовано множество книг, брошюр и статей различной направленности, содержащих упоминания о принципах сигнализации в этих сетях. На сегодняшний день, пожалуй, единственным отечественным изданием по сигнализации, включающим раздел об SS7, является книга «Сигнализация в сетях связи», написанная известным в России специалистом Б.С. Гольдштейном.

В продолжение данного материала журнал «Сети» предполагает опубликовать более подробное описание сетевых и прикладных аспектов системы сигнализации № 7.

ОБ АВТОРАХ

Константин Самуйлов — заведующий кафедрой, Марина Галентовская — сотрудник кафедры «Системы телекоммуникаций» Российского университета дружбы народов. С ними можно связаться по тел. 952-2823 или по электронной почте: Konstantin.Samouylov@mx.pfu.edu.ru и mgalen@mx.pfu.edu.ru.

Дополнительные источники информации

1. Гольдштейн Б.С. Сигнализация в сетях связи. — М.,: Радио и связь, 1997.

2. Russell. T. Signaling System No.7., McGraw-Hill, Inc, 1995.

3. Самуйлов К.Е., Никитина М.В. Сети сотовой подвижной связи в стандарте GSM//Сети, 1996, № 6.

4. Самуйлов К.Е. Введение в архитектурную концепцию интеллектуальной сети//Открытые системы, 1996, № 2.

5. Неплохое описание системы SS7 и ссылки на дополнительные источники информации можно найти на сервере компании MicroLegend (http://www.microlegend.com).

6. Вводное руководство по SS7 можно найти в Internet по адресу http://www.webproforum.com/bell-atlantic2/.

7. Материалы о развитии стандарта SS7 и его поддержке производителями регулярно публикует журнал Intenet Telephony (http://www.internettelephony.com).