Каждый ASE поддерживает одну или несколько операций. Согласно рекомендации ITU-T X.219 под операцией (operation) понимается совокупность действий, которые должен выполнить функциональный объект, получив соответствующий запрос (request) от другого функционального объекта. В ответ на запрос может последовать отклик (response), несущий информацию либо о результате выполнения этих действий, либо о невозможности их выполнить.
Использование механизма согласования прикладного контекста АС, определенного в рекомендациях ITU-T серии Q.77X, позволяет двум взаимодействующим элементам точно идентифицировать свои характеристики, а также и те характеристики, которыми должен обладать используемый для взаимодействия интерфейс.
Исходя из проведенного в разделе анализа базовых концептуальных принципов и структуры построения интеллектуальных сетей, можно сделать следующие выводы:
- целью создания платформы IN является интегрирование возможностей средств передачи и обработки данных для предоставления услуг пользователям на базе различных телекоммуникационных сетей;
- интеллектуальная сеть имеет иерархическую четырех плоскостную структуру, в которой выделяется шесть основных узлов;
- узлы IN выполняют одну или несколько функций, которые можно разделить на три основные категории: функции, относящиеся к управлению вызовом; функции, относящиеся к управлению услугами и функции, обеспечивающие услуги;
- взаимодействие сетевых ресурсов и размещенных в них функций при предоставлении IN обеспечивается прикладным протоколом INAP, который и определяет основные необходимые для этого операции и действия в виде соответствующих сценариев.
Однако следует отметить, что состав информационных потоков между узлами интеллектуальной сети реализации сценариев INAP по обслуживанию вызовов и предоставлению интеллектуальных услуг определяет базовая модель состояний вызова, которая описывает точки взаимодействия с «логикой услуги» IN. Протокол INAP и базовая модель состояний вызова, являются основой при организации системы управления вызовами в IN.
Отсюда на основании вышеизложенного и в соответствии с техническим заданием к дипломной работе, тема которой носит комплексный характер, далее проводится анализ методики обработки вызовов IN на приемной стороне, что соответствует основным задачам по проведению исследований в данной части дипломной работе.
2. Анализ методики обработки вызовов in на приемной стороне
2.1 Обобщенная модель обслуживания вызовов в интеллектуальных сетях
В общем случае обработка вызовов является одной из функций, которые должна выполнять телефонная станция в качестве центра обработки и установления соединений в телефонной сети. В рамках архитектурной концепции построения интеллектуальной сети телефонная станция представлена узлом SSP. Для понимания процессов, происходящих в SSP при установлении соединения и при наблюдении за ним вплоть до разъединения, удобно использовать модель базового процесса обслуживания вызова. Модель содержит последовательность точек, отображающих состояния этого процесса (PIC - Point In Call), между которыми могут присутствовать точки обнаружения (DP - Detection Point) обращений к услугам IN или событий, которые представляют интерес с точки зрения логики услуг IN.
Точки PIC являются представлениями обычных действий, выполняемых коммутационной станцией во время установления соединения, и состояний, через которые проходит процесс обслуживания вызова с момента, когда абонент снял трубку, до окончания связи. Например, нулевое состояние - это состояние, в котором SSP следит за свободной абонентской линией. В качестве других состояний (или точек PIC) можно назвать состояние вызова абонентом станции («трубка снята»), состояние, когда станция принимает набираемые абонентом цифры номера («накопление информации»), «анализ информации», «маршрутизация», «оповещение» и т.д.
Через подобные состояния проходит процесс обслуживания вызова в любой станции (с функциями SSP или без них). Однако рассматриваемая ниже формальная модель процесса обслуживания вызова, требующего услуг IN, используется только в концепции IN, а потому любая коммутационная станция с функциями SSP должна соответствовать этой модели. Эта модель, содержащая в себе модель базового процесса обслуживания вызова во взаимодействии с логикой услуг IN, приведена на рисунке 2.1.
Рисунок 2.1 - Обобщенная модель процесса обслуживания вызова
Точки обнаружения обращений к услугам IN или триггерные точки (Trigger Detection Points, ТDР), отмечают приостановку базового процесса обслуживания вызова для обращения к логике услуг IN, происходящую в соответствии с заранее назначенным критерием. Таким критерием могут быть определенное сочетание цифр в набранном абонентом номере, префикс, категория вызывающей абонентской линии и т.д. Важно отметить, что эксплуатационный персонал SSP может самостоятельно определять триггерные точки (т.е. делать их обнаруживаемыми) и назначать критерии для обращения к IN.
Кроме триггерных точек, назначаемых статически для каждого набора CS, определены также назначаемые динамически со стороны SCP точки обнаружения событий (Event Detection Point, 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].
В приложении А приведена модель внутренних ресурсов CCF/SSF на передающей стороне одной АТС и приемной стороне другой АТС, которые выступают в аспекте архитектуры интеллектуальной сети как узлы SSP. Как было показано ранее, предусматриваемые концепцией IN средства моделирования обслуживания вызовов функциями CCF/SSF используют абстрактное представление процессов обслуживания вызовов и установления соединений, не зависящее от реализации оборудования и от его производителя.
С точки зрения функций IN модель CCF/SSF содержит следующие основные блоки: ВСМ - менеджер базового процесса обслуживания вызова, IN-SM (IN-Switching Manager) - менеджер коммутации услуг IN, FIM/CM (Feature Interaction Manager/Call Manager) - менеджер взаимодействия между услугами.
ВСМ является абстрактным представлением той части коммутационной станции, в которой реализованы базовые функции управления связью пользователя и установлением соединений между пользователями. Он отслеживает происходящие в процессе управления события, о которых необходимо известить SCF. Кроме того, в ВСМ реализована модель состояний базового процесса обслуживания вызовов (Basic Call State Model, BCSM) и функции обработки точек обнаружения DP.
IN-SM служит интерфейсом, который делает видимыми для SCF события, происходящие в CCF/SSF, и обеспечивает доступ SCF к ресурсам CCF/SSF. Основную часть IN-SM составляет модель состояний процесса коммутации услуг IN-SSM (IN-Switching State Model), представляющая процесс обслуживания вызова ИС функциями CCF/SSF в терминах состояний соединения.
IN-SSM создается при каждом обращении к логике услуг IN, требующем управления соединением. Создание IN-SSM либо является следствием того, что в БМСВ встречается TDP, либо инициируется со стороны SCF независимо от наличия TDP. В задачу TDP входит инициирование и прекращение управляющей связи. Разрушается IN-SSM после того, как со стороны SCF получена информация о завершении работы логики услуги.
Функции SCF могут управлять несколькими трактами и соединениями при поддержке нескольких одновременно активных BCSM. В связи с этим, в числе прочего, необходима координация действий, обусловленных одновременно возникающими в разных BCSM событиями, и действий по приостановке / возобновлению процессов обслуживания, происходящих в разных BCSM, но относящихся к одному IN-SSM.
FIM/CM предусматривает механизм, обеспечивающий поддержку нескольких одновременных обращений к логике услуг (как ИС, так и обычных) при обслуживании одного вызова. В частности, он может предотвращать одновременное обращение к логике услуг. Таким образом, FIM/CM предоставляет функциям SSF унифицированную информацию о процессе обслуживания вызова.
2.3 Структура базовой модели состояний вызова на приемной стороне и ее анализ
2.3.1 Структура BCSM на приемной стороне
BCSM является описанием деятельности функции CCF на языке конечных автоматов. Эта модель показывает, как отдельные действия CCF соединяются вместе с целью обслуживания вызова, с целью установления и обеспечения соединительных путей для пользователей. Не все аспекты BCSM явно видны со стороны логики услуги IN, а только те, что передаются из CCF в SSF и далее в SCF, и только последние являются объектом стандартизации. С этой точки зрения BCSM является средством описания действий CCF и выбора тех аспектов BCSM, которые должны быть видны со стороны логики услуг IN, контролируемой в SCF.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
