Базовый процесс обработки вызовов 
p align="left">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 | 2 | 3 | | Функции, относящиеся к управлению вызовом | | SSF | Service Switching Function (Функция коммутации услуг) | Обеспечивает интерфейс между SCF и CCF | | SRF | Specialized Resources Function (Функция специализированных ресурсов) | Обеспечивает доступ сетевых объектов к различным категориям сетевых средств (речевой автоинформатор, мосты конференц-связи и т.п.) | | CCF | Call Control Function (Функция управления вызовом) | Обеспечивает традиционные возможности обслуживания вызовов | | CCAF | Call Control Agent Function (Функция управления доступом вызова) | Обеспечивает доступ пользователя в сеть, т.е. является интерфейсом между пользователем и функцией CCF | | Функции, относящиеся к управлению услугами | | SCF | Service Control Functin (Функция управления услугами) | Определяет логику услуг IN и управляет услугой, связанной с выполняемым процессом | | SDF | Service Data Function (Функция поддержки данных услуг) | Управляет доступом услуг к базам данных сети и обеспечивает контроль данных. Обеспечивае логическую связь функции SCF с данными, «закрывая» от нее их реальное представление | | Функции, относящиеся к обеспечению услуг | | SCEF | Service Creation Environment Function (Функция среды создания услуг) | Используется для спецификации, создания, тестирования и загрузки программ логики услуг IN | | SMAF | Service Management Access Function (Функция доступа к системе эксплуатационной поддержки и администрирования услуг) | Обеспечивает интерфейс к функции SMF. | | SMF | Service Management Function (Функция эксплуатационной поддержки и администрирования услуг) | Обеспечивает предоставление услуг IN и административное управление услугами. | | |
Эталонные точки, представлены на рис. 1.6 и соответствуют функциональным интерфейсам, приведенным в табл. 1.3. Рисунок 1.6 - Функциональные связи и эталонные точки IN для CS_1Таблица 1.3 - Функциональные интерфейсы интеллектуальной сети|
Эталонная точка | Интерфейс | Эталонная точка | Интерфейс | | А В С D Е F G | CCAF-CCF CCF-CCF CCF-SRF SSF-SCF SCF-SRF SCF-SDF SMF-SCF | НIJ К L М | SMF-SDF SMF-SRF SMF-SMAF SMF-SCEF SSF-CCF SMF-SSF | | |
Для 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):
Страницы: 1, 2, 3, 4, 5, 6
|
|
