Концепция, архитектура и свойства интеллектуальных сетей
Информационный обмен и предоставление интеллектуальных услуг в IN
Информационный обмен в IN
Назначение, основные понятия и особенности протокола INAP
Архитектура прикладного протокола интеллектуальной сети
Основные компоненты и общая характеристика системы управления вызовами в интеллектуальной сети
Основные фазы вызова BCSM на приемной стороне
Функционирование модели внутренних ресурсов CCF/SSF как системы управления вызовами
Аналитические решения для простейших полумарковских процессов
Разработка алгоритма функционирования базовой модели управления вызовами на приемной стороне
Расчет вероятностно-временных характеристик базовой модели управления вызовами на приемной стороне
Навигация
Назначение, основные понятия и особенности протокола INAP
Базовый процесс обработки вызовов
106915
знаков
5
таблиц
18
изображений
1.5.2 Назначение, основные понятия и особенности протокола INAP
Как было показано, принципы создания, предоставления, и управления услугами в рамках архитектурной концепции IN определяются концептуальной моделью, содержащей четыре плоскости (рис. 1.3). На распределенной функциональной плоскости модели действия, выполняемые разными блоками SIB, объединяются в группы, называемые функциональными объектами. При внедрении услуг интеллектуальной сети эти функциональные объекты могут гибко распределяться по физическим элементам сети – узлам IN. В процессе предоставления услуг IN функциональные объекты из разных физических элементов взаимодействуют друг с другом, причем взаимодействие происходит в форме диалога: один функциональный объект запрашивает выполнение операции, а другой выполняет ее и возвращает первому результат [12].
Все необходимые для этого связи между физическими элементами сети осуществляются через стандартизованные интерфейсы (рис. 1.6). Специально для поддержки информационных потоков между узлами IN специфицирован прикладной протокол интеллектуальной сети INAP (Intelligent Network Application Protocol), который определяет синтаксис и семантику вызываемых операций, назначение и порядок их обработки. Данный протокол поддерживается системой сигнализации ОКС №7 и цифровой абонентской системой сигнализации DSS1.
Протокол INAP представляет собой прикладной протокол, т.е. протокол 7‑го уровня модели взаимодействия открытых систем (ВОС). Он предоставляет услуги для поддержки взаимодействия между прикладными процессами (АР – Application Process), происходящими в узлах IN (например, в SSP, SCP, IP). Прикладной процесс является самым верхним уровнем абстрактного представления в INAP и описывает обработку запроса услуги в узле сети. Один прикладной процесс может использовать несколько прикладных объектов (Application Entity, АЕ), каждый из которых поддерживает специфический набор функций (например, SSF АЕ, SRF АЕ, SCF АЕ), обеспечивающих взаимодействие с удаленными прикладными процессами.
АЕ представляет собой абстрактное описание функций, которые могут быть востребованы прикладным процессом АР для взаимодействия с удаленным АР. АЕ содержит определение каждой функции и правила использования этих функций. Базовым компонентом объекта АЕ является прикладной сервисный элемент (Application Service Element, ASE).
ASE объединяет в себе группу логически связанных функций, которые, в соответствии с рекомендацией ITU-T Q.775, могут быть использованы более чем одним АЕ. Применительно к интеллектуальной сети, ASE представляют собой набор спецификаций процедур обслуживания вызова, известных как операции, например InitialDP и др. Если в SSF, например, обнаружена точка DP, инициализирующая услугу и требующая участия SCF, то функция SSF формирует сообщение, которое называется InitialDP Operation, и посредством подсистемы транзакций ТСАР (Transaction Capabilities Application Part), где, в свою очередь, еще выделены два подуровня, начинается сеанс связи с соответствующими уровнями протоколов контроллера SCP. При этом используются, как будет показано дальше, также подсистема контроля соединений сигнализации системы сигнализации ОКС №7.
Прикладной процесс (например, в SSP) устанавливает логическую связь (так называемую ассоциацию), пользуясь которой, он будет взаимодействовать с другим прикладным процессом (например, в SCP), после чего начинается операций. Существуют определенные правила, в соответствии с которыми устанавливается порядок выполнения операций. За последовательность операций в ASE отвечает специальная функция. Если существует всего одна ассоциация, это – функция управления одиночной (отдельной) ассоциацией SACF (Single Association Control Function). Если одновременно имеется несколько ассоциаций, необходима синхронизация взаимодействия во всех установленных ассоциациях, которую обеспечивает общая для всех SACF функция управления множеством ассоциаций (Multiple Association Control Function, MACF).
Все средства (ассоциация, относящиеся к ней ASE, функции SACF), которые поддерживают диалог между двумя функциональными объектами, размещенными в разных узлах IN (например, диалог между SSF и SCF), образуют объект одиночной логической связи SAO (Single Association Object). На рисунке 1.7 приведена структура прикладного объекта AE.
Рисунок 1.7 – Структура прикладного объекта AE
Так, например, какой-либо абонент хочет получить обычную телефонную связь с другим абонентом. Будем рассматривать процесс организации этой связи как прикладной процесс (АР). При этом телефонный аппарат будет прикладным объектом (АЕ), который содержит следующие прикладные сервисные элементы (ASE): рычаг аппарата – «ASE – Рычаг», клавиши для набора цифр – «ASE – Цифры», клавиши для набора специальных символов – «ASE-*, #» и т.п. Все эти ASE участвуют в установлении соединения через телефонную сеть, иными словами, в создании ассоциации. Функции управления одиночной ассоциацией – SACF – должны в этом случае содержать, например, правило, говорящее о том, что перед набором номера трубка должна быть снята с рычага. Если телефонный аппарат поддерживает соединения по двум линиям, то нужны еще и функции управления множеством ассоциаций MACF, которые содержат правила переключения с одной линии на другую, а также правила объединения или разделения линий.
Протокол INAP является пользователем протокола ROSE (Remote Operations Service Element – сервисный элемент удаленных операций), определенного в рекомендациях ITU-T X.219 и Х.229, в том смысле, что INAP использует для переноса своей информации блоки данных протокола ROSE. Протокол ROSE содержится внутри подуровня компонентов ТСАР системы сигнализации ОКС №7 (ITU-T Q.771–775) и DSS1 (ITU-T Q.932) и является стандартизованным прикладным сервисным элементом. Поскольку ROSE предоставляет услуги вызова удаленных процедур, он используется во многих приложениях с распределенной обработкой. Для него определены четыре типа блоков данных протокола (Protocol Data Unit, PDU):
– Invoke – обращение;
– Return Result – возврат результата;
– Return Error – возврат ошибки;
– Reject – отказ.
Последним понятием, относящимся к определению прикладного протокола, является прикладной контекст (Application Context, АС). Формально прикладной контекст может быть определен как набор ASE и правил, которые должны соблюдаться при взаимодействии прикладных процессов друг с другом. Прикладной процесс, который инициировал взаимодействие, предлагает один или более контекстов в блоке данных (PDU) и получает ответ, в котором возможность использования контекста либо подтверждается, либо отвергается, либо предлагается другой контекст. В последнем случае текущая ассоциация должна быть закрыта, и открыта новая для представления нового набора прикладных контекстов.
Таким образом, охарактеризовав протокол в INАР соответствии с вышеприведенными понятиями прикладного процесса, прикладного объекта, прикладного сервисного элемента, прикладного контекста, а также протоколов ROSE и PDU, рассмотрим и проанализируем особенности протокола INAP.
1) Услуги, предоставляемые протоколом INAP.
Семантика услуг, предоставляемых протоколом INAP, определена на распределенной функциональной плоскости концептуальной модели IN. Основной задачей протокола INAP является перенос информации, которой обмениваются функциональные объекты FE и которая определена в информационных потоках IF и в соответствующих информационных элементах IE. Отличительной особенностью протокола INAP в данном случае является то, что он отвечает за обмен информацией между функциональными объектами ЕЕ, а не физическими объектами – узлами интеллектуальной сети. В частности, рекомендация ITU-T Q.1208, в которой изложены ключевые принципы архитектурной концепции IN гласит: «Протоколы должны быть определены таким образом, чтобы функциональные объекты можно было размещать по физическим элементам любым способом по желанию операторов и производителей оборудования» [13].
2) Словарь INAP.
Словарь протокола INAP состоит из операций, поддерживаемых протоколом ROSE, и их параметров, которые, в свою очередь, соответствуют представленным на распределенной функциональной плоскости информационным потокам и информационным элементам [3, 4].
3) Кодирование INAP.
Рекомендация ITU-T Q.I208 предписывает использовать для кодирования протокола INAP язык абстрактных описаний – ASN. 1. Язык ASN. 1 подобен языку Pascal и предназначен для независимого от кодирования определения блоков данных PDU прикладного уровня, которые, сами по себе, являются структурами данных. Язык ASN.1 содержит набор элементарных типов данных и способов создания структурированных типов данных из элементарных типов данных [4].
3) Процедуры INAP.
Процедуры протокола INAP выполняют функции синхронизации действий относящихся как к приему, так и к передаче сообщений между взаимодействующими объектами. Однако процедуры вызывают основные проблемы в процессе распределенной обработки. В то время как ошибки в синтаксисе протокола могут быть легко обнаружены и откорректированы человеком, нарушения в синхронизации являются настолько сложными, что их фактически невозможно выявить на стадии проектирования. Это ведет к непредсказуемому поведению системы, вследствие чего нормальную ситуацию бывает невозможно восстановить.
В рекомендациях ITU-T процедуры протокола обычно специфицируются двумя методами: стрелочными диаграммами (MSC‑диаграммы) и описанием на языке SDL. MSC‑диаграммы наглядно показывают общую картину обмена сообщениями между взаимодействующими объектами и служат для иллюстрации основной идеи протокола. Но с их помощью невозможно отразить все многообразие сочетаний сообщений, учитывающее все возможные ошибочные случаи. Описания на языке SDL охватывают все возможные ситуации; а также существуют специальные отладочные средства, позволяющие проверить правильность разработанных SDL‑описаний. Отмеченные достоинства разумеется, сказываются на объеме SDL‑описаний и их обозримости. Данные обстоятельства наглядно иллюстрирует приложение к обновленной редакции Q.1218, в котором содержится полный набор SDL‑описаний всех процедур относящихся к набору CS‑1 [14].
На основании изложенных понятий и особенностей, касающихся протокола INAP, перейдем к рассмотрению архитектурных принципов реализации данного протокола.
Похожие работы
... сети телекоммуникаций, а также сравнивая технические возможности оборудований различных фирм в настоящем дипломном проекте предлагаю создать интеллектуальную сеть в г.Кокшетау на базе оборудования S-12 фирмы Alcatel [6]. Выбор оборудования не случаен, так как на сети города полностью эксплуатируется данная система. Это позволяет оптимально решить вопросы по синхронизации, сигнализации и по ...
... -систем в единую сеть, но и позволяет предоставить абонентам более широкий набор телекоммуникационных услуг, включая дуплексную связь. Рис. 5.6. Многозоновая сеть LTR на базе коммутаторов FASTNet, использующая коммутируемые линии ТФОП 5.4. СИСТЕМА MULTI-NET Состав и структура системы Система Multi-Net предназначена для создания многозоновых сетей связи большой протяженности ...
... оконечной станции. Спектр линейного сигнала симметричный и достаточно высокочастотный, присутствуют также низкочастотные и постоянная составляющие. Постановка задачи Проведя анализ по модернизации существующих сооружений сети телекоммуникаций района АТС-38, ставим задачу для нашего дипломного проектирования: 1.Увеличить номерную емкость района АТС-38 заменой существующей РАТС типа АТСКУ 10000, ...
... мобильной и фиксированной телефонной связью; в перспективе, не должно быть никакой разницы между мобильным и домашним телефонами. 2. Анализ вопросов проектирования сотовой системы связи стандарта DCS-1800 оператора «Астелит» 2.1 Расчет величины дуплексного разноса между частотными каналами Величина дуплексного разноса определяется соотношением [6] = - = -, (2.1) где ...
0 комментариев