перейти к полному списку дипломных проектов
Ссылка на скачивания файла в формате .doc находится в конце странички
На основании изложенных понятий и особенностей, касающихся протокола 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, перейдем к рассмотрению архитектурных принципов реализации данного протокола.
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.
скачать бесплатно Анализ базовых концептуальных принципов и структуры построения интеллектуальных сетей
Содержание дипломной работы
Каждый этап имеет свою логику развития, взаимосвязь с предыдущими и последующими этапами
212 вся совокупность услуг, предоставляемых сетью, делится на две группы: основные услуги и дополнительные виды обслуживания (ДВО)
Прежняя стратегия ввода новых ДВО основывалась на замене старой (с меньшим набором ДВО) версии программного обеспечения (ПО) на всех узлах сети на новую (с новым набором ДВО)
В результате такого взаимодействия может быть обеспечена услуга или компонент услуги
3) SDP (Service Data Point) – узел базы данных услуг, содержащий данные, используемые программами логики услуги, чтобы обеспечить индивидуальность услуги
1 – Услуги набора CS 1
Услуги, предоставляемые набором возможностей CS 1 имеют в общем 38 свойств
Интерпретатор вида услуги получает подтверждение о реализуемости запрошенной услуги и начинает контроль ее реализации путем обмена в реальном времени с ПКУ
Здесь будет установлено соединение с абонентом Б с помощью стандартных средств и протоколов коммутируемой сети, а программа реализации услуги позволит начислить оплату за ИУ абоненту Б
Данный протокол поддерживается системой сигнализации ОКС №7 и цифровой абонентской системой сигнализации DSS1
Формально прикладной контекст может быть определен как набор ASE и правил, которые должны соблюдаться при взаимодействии прикладных процессов друг с другом
На основании изложенных понятий и особенностей, касающихся протокола INAP, перейдем к рассмотрению архитектурных принципов реализации данного протокола
Таким критерием могут быть определенное сочетание цифр в набранном абонентом номере, префикс, категория вызывающей абонентской линии и т
Создание IN-SSM либо является следствием того, что в БМСВ встречается TDP, либо инициируется со стороны SCF независимо от наличия TDP
Первые шесть относятся к BCSM на передающей стороне, а вторые пять – к BCSM на приемной стороне
Функции: передача индикации ответа вызываемой стороны к BCSM на исходящей стороне; установление соединения между исходящей и входящей сторонами, наблюдение за состоянием связи
4 Функционирование модели внутренних ресурсов CCF/SSF как системы управления вызовами
На основании вышеизложенного, проанализируем последовательность действий, выполняемых объектами модели CCF/SSF
FIM/CM определяет, как следует обрабатывать это событие, после чего сообщает IN-SM, что событие связано с активной в данной момент логикой услуги IN
В теории массового обслуживания случайную величину обычно рассматривают как время пребывания системы в состоянии при условии, что следующим состоянием, в которое перейдет система, будет
Обозначим через случайный момент времени попадания процесса в состояние , а через длительность пребывания процесса в этом состоянии
Обозначим через функцию плотности распределения времени пребывания процесса в состоянии 0, а через – в состоянии 1
17)
полученных из условия равенства распределений времени пребывания процесса в состоянии 1 и времени возврата в это состояние для исходного графа (рис
Разработка алгоритма функционирования базовой модели управления вызовами на приемной стороне
На основании вышеизложенного описания BCSM на приемной стороне и в соответствии с рекомендациями ITU-T Q
При этом наблюдаются следующие функции: выбор ресурса для обслуживания вызова, извещение о вызове к вызываемому терминальному оборудованию
4)
;
– при параллельном соединении дуг с весовыми функциями и эквивалентная весовая функция представляет собой сумму этих весовых функций
, (4
Вторичная обработка обеспечивает представление информации в наиболее удобной форме, анализ статистики, интеллектуальную обработку данных экспертной системой анализатора и т
Лазарев, В
12–99 Типове положення про навчання, інструктаж та перевірку знань працівників з питань охорони праці
