Базовый процесс обработки вызовов (стр. 6 из 14)

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

1.5.3 Архитектура прикладного протокола интеллектуальной сети

Чтобы блоки данных протокола PDU могли достичь физического пункта назначения независимо от того, в какой сети он находится, INAP использует адресацию подсистемы SCCP (SignalingConnectionControlPart– подсистема управления соединением сигнализации) системы сигнализации ОКС №7 (параметр «глобальный заголовок») и подсистему МТР (MessageTransferPart– подсистема передачи сообщений) – поле «код пункта сигнализации». Выбор номеров подсистем SSN (SubsystemNumbers), присваиваемых INAP внутри узла, производится оператором сети по своему усмотрению Соответствующая архитектура протокола INAP представлена на рисунке 1.8.

Рисунок 1.8 – Архитектура протокола INAP

Протокол INAP представляет собой совокупность всех прикладных сервисных элементов ASEIN. Физический элемент может взаимодействовать всего с одним другим физическим элементом (случай (а) рис. 1.8) или с несколькими другими физическими элементами (случай (b) рис. 1.8). В случае (а) координацию использования разных ASE (т.е. организацию очередности поддерживаемых этими ASE операций согласно очередности приема соответствующих примитивов) выполняет функция управления одиночной ассоциацией SACF. Эту функцию и относящиеся к ней ASE представляет объект одиночной логической связи SAO. В случае (b) координацию взаимодействия во всех установленных ассоциациях выполняет MACF– функция управления множественными ассоциациями, синхронизирующая работу нескольких разных SAO, каждый из которых взаимодействует с SAO в одном из нескольких удаленных физических объектов.

Каждый ASE поддерживает одну или несколько операций. Согласно рекомендации ITU-TX.219 под операцией (operation) понимается совокупность действий, которые должен выполнить функциональный объект, получив соответствующий запрос (request) от другого функционального объекта. В ответ на запрос может последовать отклик (response), несущий информацию либо о результате выполнения этих действий, либо о невозможности их выполнить.

Использование механизма согласования прикладного контекста АС, определенного в рекомендациях ITU-T серии Q.77X, позволяет двум взаимодействующим элементам точно идентифицировать свои характеристики, а также и те характеристики, которыми должен обладать используемый для взаимодействия интерфейс.

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

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

– интеллектуальная сеть имеет иерархическую четырех плоскостную структуру, в которой выделяется шесть основных узлов;

– узлы IN выполняют одну или несколько функций, которые можно разделить на три основные категории: функции, относящиеся к управлению вызовом; функции, относящиеся к управлению услугами и функции, обеспечивающие услуги;

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

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

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

2. Анализ методики обработки вызовов in на приемной стороне

2.1 Обобщенная модель обслуживания вызовов в интеллектуальных сетях

В общем случае обработка вызовов является одной из функций, которые должна выполнять телефонная станция в качестве центра обработки и установления соединений в телефонной сети. В рамках архитектурной концепции построения интеллектуальной сети телефонная станция представлена узлом SSP. Для понимания процессов, происходящих в SSP при установлении соединения и при наблюдении за ним вплоть до разъединения, удобно использовать модель базового процесса обслуживания вызова. Модель содержит последовательность точек, отображающих состояния этого процесса (PIC– PointInCall), между которыми могут присутствовать точки обнаружения (DP– DetectionPoint) обращений к услугам IN или событий, которые представляют интерес с точки зрения логики услуг IN.

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

Через подобные состояния проходит процесс обслуживания вызова в любой станции (с функциями SSP или без них). Однако рассматриваемая ниже формальная модель процесса обслуживания вызова, требующего услуг IN, используется только в концепции IN, а потому любая коммутационная станция с функциями SSP должна соответствовать этой модели. Эта модель, содержащая в себе модель базового процесса обслуживания вызова во взаимодействии с логикой услуг IN, приведена на рисунке 2.1.

Рисунок 2.1 – Обобщенная модель процесса обслуживания вызова

Точки обнаружения обращений к услугам IN или триггерные точки (TriggerDetectionPoints, ТDР), отмечают приостановку базового процесса обслуживания вызова для обращения к логике услуг IN, происходящую в соответствии с заранее назначенным критерием. Таким критерием могут быть определенное сочетание цифр в набранном абонентом номере, префикс, категория вызывающей абонентской линии и т.д. Важно отметить, что эксплуатационный персонал SSP может самостоятельно определять триггерные точки (т.е. делать их обнаруживаемыми) и назначать критерии для обращения к IN.

Кроме триггерных точек, назначаемых статически для каждого набора CS, определены также назначаемые динамически со стороны SCP точки обнаружения событий (EventDetectionPoint, EDP), которые интересны с точки зрения логики услуг IN. Такими событиями могут быть, например, занятость вызываемого абонента, ответ, отбой абонента и т.д. Переданная в SCP информация о том, какое именно событие наступило, используется сервисной логикой для того, чтобы принять решение о дальнейших инструкциях, которые нужно направить к SSP.

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

Рассмотрим пример работы модели. Предположим, что базовый процесс обслуживания вызова вышел из нулевого состояния, прошел состояние «трубка снята» и находится в состоянии «накопление информации». Если накопленная информация отвечает заданному критерию, процесс приостанавливается и «срабатывает» триггерная точка «информация накоплена». SSP формирует сообщение с необходимыми данными и направляет его через сеть ОКС №7 к SCP. После приема от SCP ответного сообщения, в котором содержатся инструкции для маршрутизации вызова, SSP переходит в следующее состояние «анализ информации». Далее процесс обслуживания вызова происходит обычным образом вплоть до разъединения.

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

2.2 Основные компоненты и общая характеристика системы управления вызовами в интеллектуальной сети

В соответствии с распределенной моделью CS‑1 процесс предоставления услуги интеллектуальной сетью заключается в установлении соединения объектами CCF/SSF, в выполнении логики услуги в SCF, а также в использовании вспомогательных ресурсов и данных (в объектах SRF и SDF). В рекомендации Q.1214 для CS‑1 даны модели каждого функционального объекта распределенной функциональной плоскости в виде машины конечных состояний.

Система управления вызовами в IN описывается моделью внутренних ресурсов CCF/SSF и ориентирована на услуги (атрибуты услуг) типа А, то есть на такое обслуживание вызовов, когда услуги IN предоставляются независимо вызывающей и вызываемой стороне соединения [5].