(е7) SRF Report to SCR событие имеет место, когда к SCF передается операция SpecializedResourceReport ипи возвращается результат выполнения операции PromptAndCollectUserlnformation. SRSM остается в состоянии «User interaction*.

(е8) PlayAnnouncement/PromptAndCollectUserlnformation Cancel-led to SCR это событие имеет место, когда в SCF передается ошибка выполнения операции PlayAnnouncement/PromptAndCol-lectUser Information, вызванная приемом операции Cancel (для операции PlayAnnouncement ипи PromptAndCollectUserlnforma-tion). Событие соответствует успешно:?! отмене выполняемо:?! (но еще не выполненно!?!) или буферизированно!?! операции PlayAnnouncement/ PromptAnd CollectUserlnformation. SRSM остается в состоянии «User interaction*.

(е9) Cancel Error to SCR это событие имеет место, когда в SCF передается ошибка в выполнении операции Cancel (для PlayAnnouncement ипи PromptAndCollectUserlnformation). Событие соответствует неуспешно!?! отмене операции PlayAnnouncement/ PromptAndCollectUserlnformation. SRSM остается в том же состоянии.

(ЕЮ) Connection Released from SSR это событие имеет место, когда SRSM принимает от SSF сообщение разъединения. SRSM переходит в состояние «ldle*.

(el 1) Disconnect to SSR это событие имеет место, когда SCF разрешает SRF инициировать разъединение после приема от SCF последно!?! операции PlayAnnouncement/PromptAndCollectUser Information (Е2) или (Е5). В этом случае после передачи к SCF по-следно!?! операции SpecializedResource Report ипи результата выполнения операции PromptAndCollectUserlnformation SRSM инициирует разъединение тракта связи с SSF, используя соответствующую систему сигнализации по этому тракту. SRSM переходит в состояние «ldle*.

CollectUserlnformation. SRSM переходит в состояние «User interaction* при событии (Е2) и остается в этом состоянии при последующих событиях (Е5).

• (Е6) Cancel from SCF (для операци!?! PlayAnnouncement/Prompt AndCollect Userlnformation): это событие имеет место в случае, когда от SCF была принята операция PlayAnnouncement ипи PromptAndCollectUserlnformation. Если соответствующие де1?1ст-вия уже выполняются, то они прекращаются, в противном случае операция удаляется из буфера. SRSM остается в состоянии «User interaction*.

• (el 2) SRF Sanity Timeout: событие имеет место, когда SRSM находилась в состоянии «User Interaction* в течение времени, определенного таймером Тд, не получая от SCF операций PlayAn-nouncement/PromptAndCollectUserlnformation. SRF инициирует разъединение тракта связи с SSF, используя соответствующую систему сигнализации по этому тракту. SRSM переходит в состояние «ldle».

В дополнение к отмеченным переходам, сбой при создании тракта связи между пользователем и SRF приводит к переходу SRSM в состояние «ldle» из любого состояния. С целью упрощения диаграммы такого рода переходы на рисунке 3.4.3 не показаны.

3.4.4 Примеры процедур управления SRF

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

3.4.4.1 Процедуры подключения SRF

Для разных физических сценариев требуются разные процедуры. Ниже описываются рассматриваемые нами случаи, которые иллюстрирует рисунок 3.4.4:

a) IP непосредственно подключена к SSP, который взаимодействует с SCP, или интегрирована в этот SSP, но операции от SCP транслируются к IP через SSP, выполняющий в этом случае все необходимые преобразования протоколов;

b) IP непосредственно подключена к SSP, который взаимодействует с SCP, но операции от SCP передаются к IP без переприема в SSP;

c) IP непосредственно подключена ко второму (ассистирующему) SSP или интегрирована в этот SSP. Операции от SCP транслируются к IP через второй SSP (метод ассистирования - «Assist»), а по завершении взаимодействия с пользователем управление возвращается первому SSP;

d) IP непосредственно подключена к коммутационной системе без функций SSP, при этом операции от SCP передаются к IP без переприема в SSP («Assist»-мeтoд, но с некоторым изменением физической конфигурации). По завершении взаимодействия с пользователем управление возвращается к SSP;

e) IP подключена ко второму SSP, и по завершении взаимодействия с пользователем управление обслуживанием вызова инициирую-

щему SSP не возвращается, а сохраняется за этим вторым SSP (метод передачи управления - «Handoff»).

Случай а)

Трансляция операций в SSF

Неинтегрированный SRF

Интегрированный SRF

Случай Ь)

Прямая связь между SCP и IP

Случай с)

Ассистирование Инициирующи с трансляцией sSP

Неинтегрированный SRF

Интегрированный SRF

. Ассистирующий SSP

Случай d)

ZVrZZ Инициирующий

Случай е)

Передача управления

Инициирующие SSP

SCP Неинтегрированный SRF

Интег/зированный SRF

Ассистирующий

Рис. 3.4.4 Физические сценарии процедур соединения с SRF

В каждом из этих случаев для передачи операций между SCP и SSP может использоваться протокол ТСАР системы ОКС №7; обмен операциями между SSP и IP, при трансляции через SSP, может осуществляться через систему сигнализации DSS1 с использованием информационного элемента FACILITY (в этом случае SSP должен осуществлять преобразование протоколов для операций и ответов