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

106915
знаков
5
таблиц
18
изображений

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

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

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


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

Каждый 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 переходит в следующее состояние «анализ информации». Далее процесс обслуживания вызова происходит обычным образом вплоть до разъединения.

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


Информация о работе «Базовый процесс обработки вызовов»
Раздел: Коммуникации и связь
Количество знаков с пробелами: 106915
Количество таблиц: 5
Количество изображений: 18

Похожие работы

Скачать
260457
20
40

... сети телекоммуникаций, а также сравнивая технические возможности оборудований различных фирм в настоящем дипломном проекте предлагаю создать интеллектуальную сеть в г.Кокшетау на базе оборудования S-12 фирмы Alcatel [6]. Выбор оборудования не случаен, так как на сети города полностью эксплуатируется данная система. Это позволяет оптимально решить вопросы по синхронизации, сигнализации и по ...

Скачать
58637
0
1

... -систем в единую сеть, но и позволяет предоставить абонентам более широкий набор теле­коммуникационных услуг, включая дуплексную связь. Рис. 5.6. Многозоновая сеть LTR на базе коммутаторов FASTNet, использующая коммутируемые линии ТФОП   5.4. СИСТЕМА MULTI-NET   Состав и структура системы Система Multi-Net предназначена для создания многозоновых сетей связи большой про­тяженности ...

Скачать
129463
15
13

... оконечной станции. Спектр линейного сигнала симметричный и достаточно высокочастотный, присутствуют также низкочастотные и постоянная составляющие. Постановка задачи Проведя анализ по модернизации существующих сооружений сети телекоммуникаций района АТС-38, ставим задачу для нашего дипломного проектирования: 1.Увеличить номерную емкость района АТС-38 заменой существующей РАТС типа АТСКУ 10000, ...

Скачать
103375
18
10

... мобильной и фиксированной телефонной связью; в перспективе, не должно быть никакой разницы между мобильным и домашним телефонами. 2. Анализ вопросов проектирования сотовой системы связи стандарта DCS-1800 оператора «Астелит»   2.1 Расчет величины дуплексного разноса между частотными каналами Величина дуплексного разноса определяется соотношением [6]  = - = -, (2.1) где ...

0 комментариев


Наверх