Услуги, предоставляемые набором возможностей CS_1 имеют в общем 38 свойств. Согласно Q.1211 кратко охарактеризуем некоторые основные из них.

1) ABD (Abbreviated Dialing) - сокращенный набор номера. Это свойство помогает, в частности, реализовать услугу Virtual Private Network (VPN).

2) AUTZ (Authorization Code) - код авторизации, например, набором пароля (PIN_кода) пользователь получает доступ к сети при использовании кредитной карты, а в сети VPN может снять ограничения на доступные ему номера вызываемых пользователей. Разные наборы привилегий могут иметь разные коды. Один и тот же код может быть предоставлен многим абонентам VPN.

3) AUT (Authentication) - аутентификация, установление личности вызывающего пользователя с целью предоставления ему доступа к каким-то ресурсам телефонной сети.

4) CD (Call Distribution) - автоматическое распределение входящих вызовов между двумя или более пользователями в заданной пропорции.

5) CFC (Call Forwarding on Busy/Don't Answer) - переадресация при условии занятости или не ответа вызываемого пользователя.

6) GAP (Call Gapping) - автоматическое прореживание вызовов, направляемых к пользователю, в частности, для предупреждения перегрузки на сети.

7) LIM (Call Limiter) - ограничитель вызовов, ограничение максимального числа одновременно входящих (удерживаемых) вызовов. В частности, максимальное число (порог) может меняться в реальном времени.

8) LOG (Call Logging) - запоминание входящих вызовов к какому-то заданному номеру.

9) CRG (Customized Ringing) - абонент услуги может заказать различный вызывной сигнал для заданного списка А-номеров.

10) ONE (One Number) - единый номер (на несколько линий). Абонент услуги может задавать, какие вызовы, с какой линией соединять.

11) ODR (Origin Dependent Routing) - позволяет абоненту услуги принять или отклонить вызов в зависимости от географического адреса вызова.

12) OCS (Originating Call Screening) - высвечивает на индикаторе номер входящего вызова, если он включен в заданный список, учитывая при этом географический адрес А-номера, время суток и т.п.

13) PRMC (Premium Charging) - передача части оплаты за разговор вызываемому пользователю.

14) REVC (Reverse Charging) - оплата за счет вызываемого пользователя.

1.4.2 Информационный обмен в IN

Процессы предоставления интеллектуальных услуг (ИУ) протекают в разных, рассредоточенных по территории сети, подсистемах IN, поэтому они должны быть строго согласованы. Потребность в предоставлении ИУ распознается на АТС, где имеется ПКУ, по коду, набираемому пользователем. Запрос предоставления ИУ ПКУ направляет через транспортную сеть в ИВУ. Здесь происходит определение вида ИУ. Если в ИВУ имеется собственная БД, то из нее считываются необходимые данные и ПРУ. Выполнение программы предоставления ИУ в соответствии с ее ПРУ осуществляется на АТС с программным управлением. Если в ИВУ нет собственной БД ИУ, то запрос передается через транспортную сеть во внешнюю БД (рис. 1.3). Задержка предоставления ИУ существенно зависит от скорости передачи информации между ПКУ и ИВУ и между ИВУ и БД. Поэтому реализация IN целесообразна на базе ISDN, в которой данные, необходимые для предоставления ИУ, передаются между элементами сети со скоростями не ниже, чем 64 Кбит/с.

Как уже упоминалось, каждый вызов, требующий предоставления ИУ, опознается в ПКУ. Здесь генерируется отчет со всеми параметрами вызова. Отчет в виде сообщения передается через сеть сигнализации (по протоколу ОКС №7) интерпретатору вида услуги, и проверяется возможность реализации услуги путем посылки запроса через транспортную сеть в ПАУ. В соответствии с требуемым видом услуги выполняется поиск ПРУ и сопровождающих данных в СИБД или во внешней БД. Интерпретатор вида услуги получает подтверждение о реализуемости запрошенной услуги и начинает контроль ее реализации путем обмена в реальном времени с ПКУ. Информационный обмен между ПКУ, ИВУ и ПАУ не требует специальных каналов (эти объекты IN являются узлами транспортной сети) и установления соединений и относится к транзакционному типу обмена в сети с коммутацией пакетов. Транзакция - это одноразовая обработка запроса, предполагающая передачу ответа источнику запроса о полученном результате. Каждый ПКУ обычно адресует запросы к одному ИВУ, последний может поддерживать несколько ИУ. Один ПАУ тоже может поддерживать несколько ИУ. В целях уменьшения задержки ресурсы для реализации конкретной ИУ предоставляются только одним ПАУ, если на сети их несколько.

1.4.3 Предоставление ИУ в IN

Рассмотрим процесс предоставления ИУ на примере «услуги 800». Как было отмечено, оплата за обмен в этом случае возлагается на вызываемого абонента. На рис. 1.5 показан обмен между уровнями IN при предоставлении данной услуги.

Рисунок 1.5 - Пример обмена в IN при предоставлении ДВО

Пусть абонент А, являющийся пользователем цифровой АТС, просит предоставить «услугу 800» путем набора номера 800-2345678. На этой АТС модуль ПКУ определяет по коду 800 требование на ИУ и передает запрос в ИВУ через сеть сигнализации. Запрос от ПКУ интерпретируется в ИВУ по логическому номеру заказанной услуги 2345678 как заявка на оплату разговора за счет вызываемого абонента.

Частная фирма, абонент или государственная организация по согласованию с администрацией сети получают логический номер, который заносится в СИБД. Ему ставится в соответствие определенный набор номеров телефонов, к которым может быть установлено соединение при реализации данной услуги. В приведенном примере логическому номеру 2345678 сопоставлен физический сетевой номер телефона абонента Б: 6-54-32-10. Если в пункте, где находится ИВУ, нет требуемой БД с необходимыми данными, то здесь формируется запрос для считывания данных из СИБД. Этот запрос передается через сеть сигнализации. Обмен с СИБД относится к типу транзакции. До завершения ориентирования в IN по поводу всех деталей предоставления ИУ абонент ожидает начала обслуживания, получая соответствующий оповещающий сигнал. Система управления СИБД обеспечивает считывание физического сетевого номера абонента Б. Пусть результатом пересчета логического номера 2345678 в физический будет номер абонента Б: 6-54-32-10. Сообщение об этом номере и ПРУ передаются из СИБД в ИВУ и далее в ПКУ на АТС к которой подключен абонент А. Здесь будет установлено соединение с абонентом Б с помощью стандартных средств и протоколов коммутируемой сети, а программа реализации услуги позволит начислить оплату за ИУ абоненту Б.

1.5 Особенности, назначение и архитектура прикладного протокола интеллектуальной сети

1.5.1 Функции узлов, функциональные связи и интерфейсы интеллектуальной сети

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

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

Таблица 1.2 - Функции узлов IN

Эталонные точки, представлены на рис. 1.6 и соответствуют функциональным интерфейсам, приведенным в табл. 1.3.

Рисунок 1.6 - Функциональные связи и эталонные точки IN для CS_1

Таблица 1.3 - Функциональные интерфейсы интеллектуальной сети

Для CS_1 определены только три из приведенных на рис. 1.6 связей, а именно D, Е и F. Возможности управления требуются только для первых шести из приведенного списка функциональных связей (т.е. для связей А, В, С, D. E и F). Функциональная связь в некоторой опорной точке может предусматривать один или несколько классов управления. Любое сочетание функциональной связи и класса управления называется управляющей связью. Управляющая связь обозначается строкой вида <буква>.<цифра> [4, 11], где <буква> обозначает функциональную связь, а <цифра> - класс управления. Определено четыре класса управления:

- класс 1: средства управления соединением;

- класс 2: средства управления обслуживанием вызова;

- класс 3: средства управления услугой IN;

- класс 4: средства эксплуатационного управления.

Например, D.3 означает управляющую связь между функциональными элементами SSF и SCF для класса управления 3.

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, перейдем к рассмотрению архитектурных принципов реализации данного протокола.

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

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

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.

BCSM идентифицирует состояния вызова и всего процесса установления соединения, в которых допускается взаимодействие с логикой услуги IN. Структура модели BCSM включает следующие элементы (рис. 2.2):

1) состояния или фазы вызова PIC;

2) точки обнаружения DP;

3) переходы;

4) события.

Рисунок 2.2 - Обозначение элементов БМСВ

В рамках архитектуры IN модель BCSM отражает существующий процесс коммутации базовых двусторонних вызовов и функциональное разделение между исходящим и входящим сегментами вызова [6]. Модель состоит из двух частей: BCSM на передающей и принимающей сторонах.

В соответствии с поставленными в техническом задании к дипломной работе задачах, в данной дипломной работе исследуется BCSM на приемной стороне (рис 2.3).

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

Рисунок 2.3 - Структура BCSM на приемной стороне IN для CS_1

2.3.2 Основные фазы вызова BCSM на приемной стороне

Приемная часть BCSM соответствует той части ресурсов CCF, которые несут ответственность за установление соединения к вызываемому абоненту.

Фазы вызова описаны в рекомендации ITU-T Q.1214 [15] и показаны на рис. 2.3. В соответствии с этой рекомендацией существует одиннадцать основных состояний описания модели BCSM. Первые шесть относятся к BCSM на передающей стороне, а вторые пять - к BCSM на приемной стороне. Рассмотрим состояния, относящиеся к модели BCSM на приемной стороне.

1) Состояние 7 (PIC 7) - свободное состояние и проверка правомочности запроса входящей связи.

Стартовое событие: освобождение ресурсов, занятых в предыдущем соединении (переход от DP 17 или от DP 18); окончание обработки исключительной ситуации.

Функции: освобождение линий и каналов; контроль исходного состояния; проверка правомочности входящего вызова.

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

Выходные события: индикация приема входящего вызова и разрешение направить его к адресату.

События выхода по исключению: индикация отказа со стороны передающей части или отрицательный результат проверки права входящей связи.

2) Состояние 8 (PIC 8) - выбор ресурса и извещение о принимаемом вызове.

Стартовое событие: индикация приема входящего вызова и разрешение направить его к адресату (переход от DP 12).

Функции: выбор ресурса для обслуживания вызова; подача извещения о вызове к вызываемому терминальному оборудованию (сообщения SETUP в случае ISDN или вызывного сигнала в случае аналоговой абонентской линии).

Доступная информация: та же, что для PIC 7.

Выходные события: приемная сторона извещается о вызове (переход к PIC 9); получен ответ вызываемой стороны (переход к DP 15).

События выхода по исключению: вызываемая сторона занята или недоступна (переход к DP 13); получена индикация отказа вызывающей стороны от связи (переход к DP 18).

3) Состояние 9 (PIC 9) - принимающая сторона передает оповещение (посылка вызова).

Стартовое событие: принимающая сторона извещается о вызове.

Функции: передача индикации оповещения к BSCM на исходящей стороне и ожидание ответа вызываемой стороны

Доступная информация: та же, что для PIC 8.

Выходные события: ответ вызываемой стороны (переход к DP 15).

События выхода по исключению: отсутствие ответа (переход к PIC 14); получена индикация отказа вызывающей стороны от связи (переход к DP 18).

4) Состояние 10 (РIС 10) - разговор.

Стартовое событие: ответ вызываемой стороны.

Функции: передача индикации ответа вызываемой стороны к BCSM на исходящей стороне; установление соединения между исходящей и входящей сторонами, наблюдение за состоянием связи.

Доступная информация: та же, что для PIC 9.

Выходные события: прием от вызванной стороны запроса услуги (атрибута услуги), например, кратковременное нажатие на рычаг телефонного аппарата, сигнал DTMF, сообщение DSS1 (переход к DP 16); запрос разъединения вызванной стороной или от BCSM на исходящей стороне (переход к DP 17).

5) Состояние 11 (PIC11) - освобождение.

Стартовое событие: возникновение условий, предполагающих выход по исключению из любой описанной выше точки PIC.

Функции: индикация в сторону исходящей BCSM возникновения нештатной ситуации; стандартная обработка исключительных ситуаций, предполагающая освобождение задействованных ресурсов.

Доступная информация: та, которая имеется в точке, где возникла исключительная ситуация.

Выходные события: завершение обработки исключительной ситуации функциями CCF/SSF (переход к PIC 7).

2.3.3 Точки обнаружения характерные для BCSM на приемной стороне

Точки обнаружения DP представляют собой такие точки в базовом процессе обслуживания вызова, в которых могут быть обнаружены события, представляющие интерес для логики услуг IN. В случае необходимости информация о таких событиях передается к функциям SCF. Для того, чтобы это было возможно, соответствующая DP должна быть активизирована. Только в этом случае программы логики услуг, находящиеся в SCР смогут влиять на последующее обслуживание вызова. Если DP не активизирована, то CCF/SSF продолжает работать с вызовом без обращения к SCF. Точки обнаружения характеризуются следующими атрибутами:

1) Механизмом активизации. Точки обнаружения могут быть активизированы статически или динамически. Статическая активизации производится функциями SMF (Service Management Function - функциональный объект эксплуатационного управления услугами). Такие точки остаются в активизированном состоянии до момента их деактивизации со стороны SMF. Динамическая активизация производится SCF в контексте управляющей связи между SSF и SCF при обслуживании конкретного вызова, причем DP остается активизированной до окончания этой управляющей связи.

2) Критерием. Под критерием понимаются условия, которые должны быть удовлетворены, чтобы к SCF было передано уведомление о том, что встретилась активизированная DP.

3) Логической связью. Если встречена активизированная DP и удовлетворен соответствующий ей критерий, функции SSF могут обмениваться информационными потоками с SCF, используя некую абстрактную среду, носящей название «логическая связь». Логическая связь может быть управляющей (используя ее, SCF влияет на процесс обслуживания вызова) и контрольной (используя ее, SCF может лишь вести мониторинг процесса, не оказывая на него никакого воздействия).

4) Необходимостью приостановки базового процесса обслуживания вызова. При условии, что встретилась активизированная DP, удовлетворяется соответствующий ей критерий и установлена управляющая связь, SSF может приостановить процесс обслуживания вызова для того, чтобы дать возможность функциям SCF влиять на дальнейший ход этого процесса. Если необходимость приостанавливать процесс отсутствует, функции SCF уведомляются о том, что встретилась определенная DP, но их ответная реакция не ожидается. Этот атрибут точки обнаружения назначается таким же образом, каким осуществляется ее активизация.

В соответствии с рассмотренными атрибутами для CS_1 определены четыре типа точек обнаружения:

- триггерная точка обнаружения, запрос (TDP-R);

- триггерная точка обнаружения, уведомление (TDP-N);

- точка обнаружения события, запрос (EDP-R);

- точка обнаружения события, уведомление (EDP-N).

Атрибуты перечисленных типов точек обнаружения приведены в таблице 2.1.

Таблица 2.1 - Атрибуты точек обнаружения

Страницы: 1, 2, 3, 4