Подсистема SCCP. Общие положения. Основные задачи подсистемы, страница 7

3. Синтаксические ошибки

Если подсистема SCCP обнаружила синтаксические ошибки в сообщении, то данное сообщение отбрасывается.

SCCP management

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

Таблица: примитивы SCCP management

Групповое название

Специфическое название

N-COORD

Координация

Request

Indication

Response

Confirm

N-STATE

Состояние

Request

Indication

N-PCSTATE

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

Indication

Примитив N-COORD-REQUEST используется для уведомления дублирующего узла о выводе из сервиса подсистемы пользователя. Вывод подсистемы пользователя из сервиса происходит только после получения уведомления (N-COORD-CONFIRM сообщения) о готовности принять трафик со стороны дублирующего узла.

Примитивы N-STATE (Request, Indication) используются для информирования удаленной стороны о статусе подсистемы пользователя.

Примитив N-PCSTATE используется для информирования подсистемы пользователя о статусе пункта сигнализации и статусе подсистемы SCCP.

1. Subsystem prohibited

1.1. Выход из сервиса локальной подсистемы пользователя

  • подсистема SCCP получает от локальной подсистемы пользователя примитив N-STATE-request с информацией User-out-of-service;
  • подсистема SCCP принимает решение о выводе из сервиса локальной подсистемы пользователя.

Предпринимаются следующие действия:

  • подсистема пользователя помечается как "prohibited";
  • инициируется broadcast рассылка сообщения SSP (Subsystem-prohibited) на все смежные сигнальные направления;
  • с подсистемы пользователя снимается признак "ignore subsystem status test".

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

При получении от удаленного узла сообщения SSP предпринимаются следующие действия:

  • в таблице маршрутизации данная подсистема на данном направлении помечается как "prohibited";
  • происходит местная broadcast рассылка примитивов N-STATE-indication всем местным подсистемам с информацией User-out-of-service;
  • инициируется процедура "Subsystem-test".

2. Subsystem allowed

2.1. Восстановление местной подсистемы пользователя

Данная процедура инициируется при получении от локальной подсистемы пользователя, помеченной как "prohibited", примитива N-STATE-request с информацией User-in-service. В этом случае предпринимаются следующие действия:

  • локальная подсистема помечается как "allowed";
  • инициируется broadcast рассылка сообщения SSA (Subsystem-allowed) на все смежные сигнальные направления;
  • на подсистему пользователя устанавливается признак "ignore subsystem status test".

2.2. Восстановление удаленной подсистемы пользователя

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

В этом случае предпринимаются следующие действия:

  • в таблице маршрутизации данная подсистема на данном направлении помечается как "allowed";
  • происходит местная broadcast рассылка примитивов N-STATE-indication всем местным подсистемам с информацией User-in-service;
  • деактивируется процедура "Subsystem-test".

3. Subsystem status test

Процедура Subsystem status test инициируется для удаленной подсистемы пользователя, для которой получено сообщение SSP. Также процедура может быть инициирована для предустановленного списка подсистем по определенному направлению при получении сообщения MTP-RESUME-indication или SSA с SSN=1. Процедура Subsystem status test заключается в периодической посылке сообщения SST (с периодом, равным таймеру T_stat_info).