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

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

SCCP обеспечивает два типа передачи сообщений:

• без логического соединения сигнализации (без соединения);

• с логическим соединением сигнализации (направленные на соединение).

Без логического соединения сигнализации пользователь SCCP может послать одно сообщение другому пользователю SCCP. Логическое соединение сигнализации является результатом взаимного обмена кодами исходных пунктов между SCCP в пунктах сигнализации сигнального отношения. С логическим соединением сигнализации возможен обмен сообщениями между двумя пользователями SCCP.

SCCP, в соответствии с протоколами, реализует четыре класса услуг - два для услуг без установления логического соединения и два для услуг с установлением логического соединения:

0 - Основной класс без установления логического соединения.

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

2 - Основной класс с установлением логического соединения.

3 - Класс с управлением потоком с установлением логического соединения.

Классы протокола без соединения обеспечивают возможности, соответствующие передаче одного Сервисного Блока Данных Сетевого Уровня (NSDU), (т.е. блока информации "пользователь-пользователь") в поле "данных" сообщения Блока Данных или Расширенного Блока Данных.

Когда для передачи данных пользователя одного сообщения без соединения недостаточно, для протокола клас­сов 0 и 1 обеспечивается функция сегментирования/сборки. В этом случае SCCP в исходящем начальном узле обеспечивает сегментирование информации на многократные сегменты, предшествующие передаче в поле "данных" сообщений Расширенного Блока Данных. Сегментирование будет выполняться только в исходящем начальном узле и никогда в транзитном. В узле назначения NSDU собирается.

Классы протокола, ориентированные на соединение (классы 2 и 3 протокола), обеспечивают средства для уста­новления соединения сигнализации в целях обмена большим количеством связанных NSDU. Классы протокола, ориентированные на соединение, обеспечивают также способность сегментирования и сборки. Если Сервисный Блок Данных Сетевого Уровня длиннее 255 октетов, он расщепляется на многократные сегменты в исходящем начальном узле, что предшествует информации в поле "данных" передаче сообщений Данных. Каждый сегмент меньше или равен 255 октетам. В узле назначения NSDU собирается.

Класс 0 протокола

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

Класс 1 протокола

В классе 1 протокола свойства класса 0 дополняются новым свойством (а именно: параметр управления после­довательностью связан с примитивом запроса N-UNITDATA), которая позволяет верхнему уровню указывать SCCP, что данный поток NSDU должен быть передан последовательно. В исходящих сообщениях поле выбора звена сигнализации (SLS) выбирается исходящей начальной SCCP на основании значения параметра управления последовательностью. Выбор звена сигнализации (SLS) для потока NSDU с таким же параметром управления последовательностью, будет идентичен. Затем SCCP кодирует выбор звена сигнализации (SLS) в метке маршрутизации сообщений, относящихся к таким NSDU, так что их последовательность, при нормальных условиях, обслуживается МТР и SCCP. Таким образом, этот класс соответствует расширенной услуге без со­единения, куда входит дополнительное свойство последовательности.

Класс 2 протокола

В классе 2 протокола осуществляется двусторонняя передача NSDU между пользователем SCCP в исходящем начальном узле и пользователем SCCP в узле назначения путем установления временного или постоянного со­единения сигнализации, состоящего из одного или более участков соединения. Множество соединений сигнали­зации может быть мультиплексировано на то же сигнальное отношение. Каждое соединение сигнализации в таком мультиплексируемом потоке идентифицируется использованием пары эталонных номеров, называемых "местными условными номерами". Сообщения, принадлежащие данному соединению сигнализации, будут со­держать то же значение поля SLS для обеспечения последовательности, описанной в 1.2.2. Таким образом, этот класс протокола соответствует простой сетевой услуге, ориентированной на соединение, где управление потоком передачи SCCP и обнаружение непоследовательности не обеспечивается.

Класс 3 протокола

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

Передача сообщения с SCCP

связь без установления логического соединения

связь с установлением логического соединения

Класс протокола 0

Класс протокола 1

Класс протокола 2

Класс протокола 3

Основной метод

Основной метод + управление

Основной метод

Основной метод + управление

последовательностью сообщений

потоком

Стандартный метод

Встроенный метод

Рис. 23 Классы протокола для передачи сообщений через SCCP

Различаются следующие соединения сигнализации:

• временными соединениями сигнализации;

• постоянными соединениями сигнализации.

Временные соединения сигнализации находятся под управлением пользователя SCCP.

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

Управление временными соединениями сигнализации разделено на следующие фазы:

• фаза установления соединения;

• фаза передачи данных;

• фаза освобождения соединения.

Когда функции SCCP в исходящем начальном узле получают запрос на установление соединения, для иденти­фикации узла, к которому должно быть установлено соединение сигнализации, анализируется "вызываемый адрес". Если узел не тот, SCCP направляет сообщение Запрос Соединения (CR) в исходящий пункт сигнализа­ции, используя функции МТР.

В узле, принимающем сообщение CR через функции МТР, SCCP анализирует "адрес вызываемого абонента", и выполняется одно из следующих действий:

а) Если "адрес вызываемого абонента", содержащийся в сообщении CR, относится к пользователю, на­ходящемуся в пункте назначения сигнализации и если соединение сигнализации может быть уста­новлено (т.е. существует договоренность между SCCP и местным пользователем об установлении соединения сигнализации), то сообщение Подтверждение Соединения (СС) возвращается.

b) Если "адрес вызываемого абонента" не относится к пользователю в пункте сигнализации, тогда дос­тупная информация, содержащаяся в сообщении и в узле назначения, анализируется, чтобы опреде­лить, требуется ли ассоциация двух участков соединения.

- Если ассоциация требуется, SCCP устанавливает участок (входящего) соединения сигнализации. Ус­тановление другого участка (исходящего) соединения инициируется путем передачи сообщения CR в следующий узел и этот участок соединения становится логически связанным с участком входяще­го соединения.

- Если сопряжение участка соединения в этом узле не требуется, входящее и исходящее соединения участка не устанавливаются. Сообщение CR направляется в следующий пункт назначения при по­мощи функции маршрутизации МТР.

Если SCCP получает сообщение CR и ни SCCP, ни пользователь SCCP не могут установить соединения, тогда на участок входящего соединения передается сообщение Отказано В Соединении (CREF).

При получении сообщения СС, SCCP завершает установление участка соединения. Более того, если необходимо сопряжение двух смежных участков соединения, сообщение СС направляется в предшествующий узел.

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

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

Передача каждого NSDU осуществляется одним, или более сообщениями Данные (DT); индикация больше дан­ных используется, если NSDU должен быть расщеплен на более чем одно сообщение данных (DT). Если исполь­зуется протокол класса 3, тогда управление потоком передачи утилизируется SCCP на каждом участке соедине­ния сигнализации. Если в протоколе класса 3 обнаружены ненормальные условия, тогда в соединении сигнали­зации предпринимаются соответствующие действия (например, сброс). Более того, в таком протоколе класса 3 срочные данные могут быть переданы, при помощи сообщения Срочные Данные, которое обходит процедуры управления потоком передачи, относящиеся к сообщениям Данные.

Ограниченное количество данных может быть также передано в сообщениях Запрос Соединения, Отказ В Со­единении и Соединение Освобождено.

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

Услуга установки/освобождения контролируется управлением (например OMAP). Функции для установки и освобождения могут быть подобны тем, которые предусмотрены временными соединениями сигнализации. Классы услуги - те же самые.

Постоянно устанавливаемые соединения сигнализации могут требовать дополнительных механизмов защиты внутри оконечных точек (relaypoints) соединения для того, чтобы гарантировали их установление заново в случае сбоя, сопровождаемого восстановлением.

Процедуры для услуг без соединения

SCCP обеспечивает пользователя SCCP способностью передать сообщение сигнализации через сеть сигнализации без установки соединения сигнализации. В дополнение к возможности MTP, функция "маршрутирования" должна быть организована внутри SCCP, отображая вызываемый адрес к кодам пункта сигнализации услуги MTP.

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

Когда функции SCCP в исходящем начальном узле получают от пользователя SCCP NSDU, который должен быть передан классом протокола 0 или 1 в рамках услуги без соединения, "адрес вызываемого абонента" и, если требуется, другие соответствующие параметры анализируются, чтобы идентифицировать узел, в который долж­но быть передано сообщение. Затем NSDU включается в сообщение Данные Без Соединения (UDT) или Расши­ренные Данные Без Соединения (XUDT) как параметр "данных", который передается в узел, используя функции МТР. При приеме сообщения UDT или XUDT функции SCCP в том узле выполняют анализ маршрутизации, а если пунктом назначения сообщения UDT или XUDT является местный пользователь, доставляют NSDU функциям местного вышестоящего уровня. Если "адрес вызываемого абонента" не находится в данном узле, тогда сообщения UDT и XUDT направляются непосредственно в следующий узел. Этот процесс продолжается до тех пор, пока не будет достигнут пункт назначения.

Управление последовательностью

Присутствие параметра “управление последовательностью” указывает SCCP, что пользователь требует, чтобы вызвать услугу “последовательность гарантирована”. В случае услуги “последовательность гарантирована”, этот параметр является индикацией SCCP, так что данный поток SCCP-SDUs должен быть поставлен в последовательности. Величина этого параметра вместе с вызываемым адресом используется, чтобы отличить различные потоки сообщений так, чтобы SCCP мог распределять коды SLS соответственно, чтобы помочь MTP в достижении четного распределения нагрузки. Если пользователь SCCP не обеспечивает параметром управления последовательности, то SCCP предполагает класс протокола 0.

Опция возврата

При известных условиях перегрузки и недоступности подсистем и/или пунктов сигнализации, сообщения без установления логического соединения в поддержке SCCP-SDUs могли быть отброшены вместо того, чтобы переместиться. Если пользователь SCCP хочет быть информированным относительно не передачи вызванного отбрасывающегося сообщения SCCP-SDU, параметр опции возврата должен быть установлен в примитиве " возврат SCCP-SDU по ошибке".

Параметр “опция возврата” используется, чтобы определить обработку SCCP-SDUs, сталкивающегося с проблемами перемещения. “Опция возврата” имеет значения:

• отбрасывает SCCP-SDU по ошибке ;

• возврат SCCP-SDU по ошибке.

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

Причина для возврата

Параметр “причина для возврата” идентифицирует причину, почему SCCP-SDU не был способен быть доставлен конечному назначению.

Данные пользователя

Параметр “данные пользователя” является информацией, которая должна быть перемещена между пользователями SCCP.

Сегментирование/сборка

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

Сегментирование сообщений SCCP без соединения - это прозрачно обеспечиваемая услуга к пользователю SCCP, которая позволяет передачу без соединения блока данных пользователя большего объема, содержащихся в единичном сообщении UDT или XUDT. SCCP обеспечивает эту услугу путем разбиения большого блока дан­ных пользователя на мелкие блоки (называемые сегментами), передавая сегменты как данные пользователя в сообщениях XUDT и соединяя сегменты исходящего блока данных пользователя перед их получением пользо­вателем SCCP назначения. В исходящей SCCP этот процесс называется сегментированием. В SCCP назначения этот процесс называется сборкой.

SCCP обладает своей собственной функцией маршрутирования.

Маршрутирование SCCP в СС № 7 использует три элемента:

• код пункта назначения (DPC),

• глобальный заголовок (GT),

• номер подсистемы (SSN).

Глобальный заголовок (GT)

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

Функция маршрутирования по GT поддерживает маршрутирование транзакций.

Глобальный заголовок (GT) может включать не только цифры адреса вызываемого абонента, но и другие формы адресации, которые могут быть и не признаны в сети SS № 7. Эти сообщения требуют трансляция.

Поле GT также включает в себя идентификаторы формата и глобального заголовка. В результате трансляции GT возможно получение нового GT и SSN.

Код пункта назначения (DPC)

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

DPC в адресе не транслируется и может только определять, назначено ли сообщение для данного SP (входящее сообщение), или требуются маршрутизации по сети сигнализации SS № 7 через MTP. Для входящих сообщений DPC могут быть вставлены в этикетки маршрутирования MTP.

Номер подсистемы SSN

SSN может определять доступ к подсистеме через ПУСС (SCCP) внутри узла и может быть подсистемой пользователя, например ISUP, управления SCCP или прочее. Когда проверка DPC во входящем сообщении определяет, что сообщение для этого SP, SSN определяет заинтересованного “Пользователя” SCCP.

Поле SSN первоначально имеет 255 кодов с расширением для будущих применений.

Один, два или все элементы адресации могут быть представлены в адресе вызываемой и адресе вызывающей стороны.

Основные формы адресации приведены в табл. 1:

Таблица 1

Адресация ПУСС СС № 7

DPC	Если передаются сообщения ПУСС
DPC +SSN
SSN	Если получаемые сообщения от МТР
GT
GT+SSN
DPC	Если получаемые сообщения
DPC+(SSN или GT или оба)	для маршрутизации ПУСС
GT	без установления логического соединения
GT+SSN	или ориентированного на соединение

Структура сообщений SCCP приведена на рис. 24:

Значащая сигнальная единица

Поле сигнальной информации (SIF)

необязательная часть

переменная обязательная часть

фиксированная обязательная часть

тип сообщения

этикетка маршрутирования

Направление передачи

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

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

Тип сообщения определяет функцию и формат сообщения SCCP. Различные используемые типы сообщений зависят от типа передачи сообщения.

Существуют следующие типы сообщений для передачи сообщения без соединения:

• блок передаваемых данных (UDT);

Сообщения SCCP посылаются по назначению с сообщением UDT. Это используется

для протоколов класса 0 и 1 (см. "Процедуры сигнализации").

• услуги блока передаваемых данных (UDTS);

Например, передающая SCCP информируется сообщением UDTS, что сообщени UDT

не может быть передано по назначения. UDTS используется для протоколов классов 0 и 1.

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

Параметры управления

Рассматриваемая подсистема

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

Статус пользователя

Параметр "статус пользователя" используется, чтобы сообщить пользователю SCCP относительно состояния рассматриваемой подсистемы.

"Статус пользователя " может иметь одно из значений:

• пользователь в обслуживании (UIS);

• пользователь вне обслуживания (UOS).

Индикатор множественности подсистемы

Параметр "индикатор множественности подсистемы" идентифицирует число копированной подсистемы. Этот параметр зарезервирован для национального применения.

Рассматриваемый пункт сигнализации

Параметр "рассматриваемый пункт сигнализации" идентифицирует пункт сигнализации или SCCP, который отказал переполнен, или предоставлен.

Параметр "рассматриваемый пункт сигнализации" содержит уникальную идентификацию пункта сигнализации.

Состояние пункта сигнализации

Параметр " состояние пункта сигнализации " используется, чтобы сообщить пользователю о состоянии рассматриваемого пункта сигнализации.

"Состояние Пункта сигнализации " может иметь одно из значений:

• пункт сигнализации недоступен;

• пункт сигнализации переполнен;

• пункт сигнализации доступен.

Состояние удаленного SCCP

Параметр "состояние удаленного SCCP " используется, чтобы сообщить пользователю состояние удаленного SCCP.

"Состояние удаленного SCCP " может иметь одно из значений:

• удаленный SCCP доступен;

• удаленный SCCP недоступен, неизвестные причины;

• удаленный SCCP необорудованный;

• удаленный SCCP недоступен;

• удаленный SCCP переполнен.

Уровень ограничения

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

Сообщения и параметры SCCP

Сообщения SCCP состоят из следующих частей (см. Рис. 25):

• код типа сообщения;

• обязательная фиксированная часть;

• обязательная переменная часть;

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

Этикетка маршрутирования MTP

Код типа сообщения

Обязательная фиксированная часть

Обязательная переменная часть

Необязательная часть

Рис. 25 Составные части сообщений SCCP

Общий формат сообщений SCCP приведен на рис. 26.

Message Type Code
Код типа сообщения
Mandatory Parameter A Обязательный параметр А
Mandatory Fixed Part Обязательная фиксированная часть . . .
Mandatory Parameter F Обязательный параметр F
Pointer to Parameter M Указатель на параметр M
. . .
Pointer to Parameter P Указатель на параметр P
Mandatory Variable Part Обязательная переменная часть Pointer to Start of Optional Part Указатель нач. необязательной части
Length Indicator of Parameter M Указатель длинны параметра M
Parameter M Параметр M
. . Optional Part Необязательная часть .
Length Indicator of Parameter P Указатель длинны параметра P
Parameter P Параметр P
Parameter Name = X Имя параметра = X
Length Indicator of Parameter X Указатель длинны параметра X
Parameter X Параметр X
. . .
Parameter Name = Z Имя параметра = Z
Length Indicator of Parameter Z Указатель длинны параметра Z
Parameter Z Параметр Z
End of Optional Parameter Конец необязательного параметра

Рис. 26 Общий формат сообщений SCCP

Обязательная фиксированная часть

Те параметры, которые являются обязательными и фиксированной длины для отдельного типа сообщения, содержатся в "обязательной фиксированной части ". Позиция, длина и порядок параметров однозначно определена типом сообщения.

Обязательная переменная часть

Обязательные параметры переменной длины будут включены в обязательную переменную часть. Параметры и порядка, в котором они посылаемыми, определяются типом сообщения. Имена параметра, следовательно, не включены в сообщение. Чтобы указать начало каждого параметра, используется указатель. Каждый указатель кодируется как одиночный октет или два октета в случае LUDT и LUDTS.

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

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

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

Необязательная часть

Необязательная часть состоит из непрерывного блока параметров, которые могут или не могут иметь место в любом отдельном типе сообщения. Необязательная часть может начинаться после указателя или после обязательной переменной части. Необязательные параметры могут быть переданы в любом порядке. Каждый необязательный параметр будет включать имя параметра (один октет) и индикатор длины (один октет), сопровождаемый содержанием параметра.

Конец необязательных параметров

Октет “конец необязательных параметров” включается, если только в сообщении присутствуют необязательные параметры.

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

Коды и параметры национального применения

Если для национального использования требуются коды типов сообщений и коды параметров, они должны выбираться, начиная с 11111110, в сторону убывания. Код 11111111 зарезервирован для будущего использования.

Кодирование типов сообщений SCCP

Кодирование типов сообщений приведено в Таблице 2.

Кодирование параметров SCCP

Кодирование параметров приведено в Таблице 3.

Таблица 2

Кодирование типов сообщений SCCP

Тип сообщения	Класс протокола				Код типа сообщения
	0	1	2	3
CR - Запрос соединения			X	X	0000 0001
CC - Подтверждения соединения			X	X	0000 0010
CREF - Отказ соединения			X	X	0000 0011
RLSD - Освобождение соединения			X	X	0000 0100
RLC - Полное освобождение			X	X	0000 0101
DT1 - Форма данных 1			X		0000 0110
DT2 - Форма данных 2				X	0000 0111
AK - Подтверждение данных				X	0000 1000
UDT - Блок данных	X	X			0000 1001
UDTS - Услуга блока данных	X1	X1			0000 1010
ED - Срочные данные				X	0000 1011
EA - Подтверждения приема срочных данных				X	0000 1100
RSR - Запрос сброса				X	0000 1101
RSC - Подтверждение сброса				X	0000 1110
ERR - ошибка протокола в блоке данных			X	X	0000 1111
IT - Тест пассивности			X	X	0001 0000
XUDT - Расширенный блок данных	X	X			0001 0001
XUDTS - Услуга расширенного блока данных	X1	X1			0001 0010
LUDT - Длинный блок данных	X	X			0001 0011
LUDTS - Услуга длинного блока данных	X1	X1			0001 0100
X = Тип сообщения этого класса протокола. X1 = Тип класса протокола не определен (отсутствие параметра класса протокола).

Таблица 3

Кодирование параметров SCCP

Название параметра	Код параметра 8765 4321
Конец необязательных параметров	0000 0000
Удаленная локальная ссылка	0000 0001
Исходящая локальной ссылки	0000 0010
Адрес вызываемой стороны	0000 0011
Адрес вызывающей стороны	0000 0100
Класс протокола	0000 0101
Сегментация/разборка	0000 0110
Принятый порядковый номер	0000 0111
Упорядочение/ сегментация	0000 1000
Кредит	0000 1001
Причина освобождения	0000 1010
Причина возврата	0000 1011
Причина сброса	0000 1100
Причина ошибки	0000 1101
Причина отказа	0000 1110
Данные	0000 1111
Сегментация	0001 0000
Счетчик ретрансляции	0001 0001
Важность	0001 0010
Длинные данные	0001 0011

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

Сообщения SCCP

CC (connection confirm) - подтверждение соединения: Сообщение подтверждения соединения инициализируется вызываемой SCCP, чтобы указать вызывающей SCCP, что установление соединения сигнализации выполнено. При приеме сообщения подтверждения соединения вызывающая SCCP завершает установку соединения сигнализации, если это возможно.

Это сообщение используется в течение фазы установления соединения классом протокола 2 или 3 с установлением логического соединения.

CR (connection request) запрос соединения: Сообщение запроса соединения инициализируется вызывающей SCCP к вызываемой SCCP, чтобы запросить установку соединения сигнализации между двумя объектами. Требуемые характеристики соединения сигнализации содержатся в различных полях параметра. При приеме сообщения запроса соединения вызываемая SCCP инициализирует установку соединения сигнализации, если это возможно.

Это сообщение используется в течение фазы установления соединения классом протокола 2 или 3 с установлением логического соединения.

CREF (connection refused) отказ соединения: Сообщение об отказе соединения инициализируется вызываемой SCCP или промежуточным узлом SCCP, чтобы указать вызывающей SCCP, что произошел отказ установки соединения сигнализации.

Это сообщение используется в течение фазы установления соединения классом протокола 2 или 3 с установлением логического соединения.

AK (data acknowledgement) подтверждение данных: Сообщение подтверждения данных используется, чтобы управлять механизмом управления потоком данных окна, которое было выбрано для фазы передачи данных.

Это сообщение используется в течение фазы передачи данных в классе протокола 3.

DT1 (data form) форма данных 1: Сообщение “форма данных 1” посылается к любому концу соединения сигнализации, чтобы однозначно передать данные пользователя SCCP между двумя узлами SCCP.

Это сообщение используется в течение фазы передачи данных только в классе протокола 2.

DT2 (data form 2) форма данных 2: Сообщение “форма данных 2” посылается к любому концу соединения сигнализации, чтобы однозначно передать данные пользователя SCCP между двумя узлами SCCP. При этом сообщения подтверждения следуют в другом направлении.

Это сообщение используется в течение фазы передачи данных только в классе протокола 3.

ED (expedited data) срочные данные: Функции сообщения “срочные данные” такие же, как и сообщения “форма данных 2”, но еще включает возможность обойти механизм управления потоком данных, который был выбран для фазы передачи данных. Это сообщение может быть послано к любому концу соединения сигнализации.

Это сообщение используется в течение фазы передачи данных только в классе протокола 3.

EA (expedited data acknowledgement) подтверждение срочных данных: Сообщение подтверждения ожидаемых данных используется, чтобы подтвердить сообщение срочных данных. Каждое сообщение ED должно быть подтверждено сообщением EA прежде, чем другое сообщение ED может быть послано.

Это сообщение используется в течение фазы передачи данных только в классе протокола 3.

IT (inactivity test) тест пассивности: Сообщение теста пассивности может посылаться периодически к любому концу отрезка соединения сигнализации, чтобы проверить, является ли это соединение сигнализации активным на обоих концах и, чтобы проверить непротиворечивость данных соединения на обоих концах.

Это сообщение используется в классах протокола 2 и 3.

ERR (protocol data unit error) ошибка протокола в блоке данных: Сообщение об ошибке протокола в блоке данных посылается при обнаружении любых ошибок протокола.

Это сообщение используется в течение фазы передачи данных в классах протокола 2 и 3.

RLSD (released) освобождение соединения: Сообщение об освобождении посылается в прямом или обратном направлении, чтобы указывать, что SCCP хочет освобождать соединение сигнализации и соответствующие ресурсы. Оно также указывает, что принимающий узел должен освободить соединение, а также соответствующие ресурсы.

Это сообщение используется в течение фазы освобождения соединения в классах протокола 2 и 3.

RLC (release complete) полное освобождение: Сообщение о полном освобождении посылается в ответ на сообщение об освобождении и указывает, что сообщение об освобождении было получено, и соответствующие процедуры были завершены.

Это сообщение используется в течение фазы освобождения соединения в классах протокола 2 и 3.

RSC (reset confirm) подтветждение сброса: Сообщение подтверждения сброса посылается в ответ на сообщение о запросе сброса, чтобы указать, что запрос сброса был получен, и соответствующая процедура была завершена.

Это сообщение используется в течение фазы передачи данных в классе протокола 3.

RSR (reset request) запрос сброса: Сообщение о запросе сброса посылается, чтобы указать, что посылающая SCCP хочет инициализировать процедуру сброса (повторную инициализацию) принимающей SCCP.

Это сообщение используется в течение фазы передачи данных в классе протокола 3.

SSA (subsystem-allowed) подсистема разрешена: Сообщение о разрешении подсистемы посылается на соответствующие назначения, чтобы сообщить этим назначениям, что подсистема, которая была прежде запрещена, теперь разрешена или, что SCCP, которая была прежде недоступна, является теперь доступной.

Это сообщение используется для управления SCCP.

SOG (subsystem-out-of-service-grant) предоставление выхода подсистемы: Сообщение о предоставлении выхода подсистемы посылается к запрашивающей SCCP в ответ на сообщение о запросе выхода подсистемы, если и запрошенная SCCP и резервная копия запрашиваемой подсистемы соглашаются на запрос.

Это сообщение используется для управления SCCP.

SOR (subsystem-out-of-service-request) запрос выхода подсистемы: Сообщение о запросе подсистемы используется, чтобы позволить подсистемам выйти из работы без ухудшения эффективности сети. Когда подсистема хочет выйти из работы, запрос передается посредством сообщения о запросе выхода подсистемы между SCCP в узле подсистемы и резервных подсистем.

Это сообщение используется для управления SCCP.

SSP (subsystem-prohibited) подсистема запрещена: Сообщение о запрещении подсистемы посылается к соответствующим назначениям, чтобы сообщить управлению SCCP (SCMG) этих назначений о сбое в подсистеме.

Это сообщение используется для управления SCCP.

SST (subsystem-status-test) тестирование состояния подсистемы: Сообщение о тестировании состояния подсистемы посылается, чтобы проверить состояние подсистемы, отмеченной как запрещенной или недоступной.

Это сообщение используется для управления SCCP.

UDT (unitdata) блок данных: Сообщение о блоке данных может использоваться SCCP, желающей послать данные в режиме без установления логического соединения.

Это сообщение используется в классе протокола 0 и 1 без установления логического соединения.

UDTS (unitdata service) услуга блока данных: Сообщение услуги блока данных используется, чтобы указать исходящей SCCP, что посылаемый UDT не может быть доставлен по своему назначению. Исключительно по согласованию протокола UDTS можно использовать в ответ на сообщения XUDT или LUDT. Сообщение UDTS посылается только тогда, когда поле опции в UDT установлено в "возврат по ошибке".

Это сообщение используется в классе протокола 0 и 1 без установления логического соединения.

XUDT (extended unitdata) расширенный блок данных: Сообщение расширенного блока данных используется SCCP, желающей послать данные (наряду с необязательными параметрами) в режиме без установления логического соединения.

Это сообщение используется в классе протокола 0 и 1 без установления логического соединения.

XUDTS (extended unitdata service) услуга расширенного блока данных: Сообщение услуги расширенного блока данных используется, чтобы указать исходящей SCCP, что XUDT не может быть доставлен по назначению. Исключительно по согласованию протокола XUDTS можно использовать в ответ на сообщения UDT или LUDT. Сообщение XUDTS посылается только, когда в XUDT (или возможно LUDT) установлена опция “возврат по ошибке”.

Это сообщение используется в классе протокола 0 и 1 без установления логического соединения.

SSC (subsystem congested) подсистема перегружена: Сообщение “подсистема перегружена” посылается узлом SCCP, когда он испытывает перегрузку.

Это сообщение используется для управления SCCP.

LUDT (long unitdata) длинный блок данных: Сообщение о длинном блоке данных используется SCCP, чтобы посылать данные (наряду с необязательными параметрами) в режиме без установления логического соединения. Когда возможности MTP согласно Рекомендации Q.2210 присутствуют, позволяется посылать NSDU, размером до 3952 октетов без сегментации.

Это сообщение используется в классе протокола 0 и 1 без установления логического соединения.

LUDTS (long unitdata service) услуга длинного блока данных: Сообщение об услуге длинного блока данных используется, чтобы указать исходящей SCCP, что LUDT не может быть доставлен по назначению. Сообщение LUDTS посылается только тогда, когда в LUDT установлена опция “возврат по ошибке”.

Это сообщение используется в классе протокола 0 и 1 без установления логического соединения.