Базовый процесс обработки вызовов (стр. 4 из 14)
1) ABD (AbbreviatedDialing) – сокращенный набор номера. Это свойство помогает, в частности, реализовать услугу VirtualPrivateNetwork (VPN).
2) AUTZ (AuthorizationCode) – код авторизации, например, набором пароля (PIN‑кода) пользователь получает доступ к сети при использовании кредитной карты, а в сети VPN может снять ограничения на доступные ему номера вызываемых пользователей. Разные наборы привилегий могут иметь разные коды. Один и тот же код может быть предоставлен многим абонентам VPN.
3) AUT (Authentication) – аутентификация, установление личности вызывающего пользователя с целью предоставления ему доступа к каким-то ресурсам телефонной сети.
4) CD (CallDistribution) – автоматическое распределение входящих вызовов между двумя или более пользователями в заданной пропорции.
5) CFC (CallForwardingonBusy/Don’tAnswer) – переадресация при условии занятости или не ответа вызываемого пользователя.
6) GAP (CallGapping) – автоматическое прореживание вызовов, направляемых к пользователю, в частности, для предупреждения перегрузки на сети.
7) LIM (CallLimiter) – ограничитель вызовов, ограничение максимального числа одновременно входящих (удерживаемых) вызовов. В частности, максимальное число (порог) может меняться в реальном времени.
8) LOG (CallLogging) – запоминание входящих вызовов к какому-то заданному номеру.
9) CRG (CustomizedRinging) – абонент услуги может заказать различный вызывной сигнал для заданного списка А-номеров.
10) ONE (OneNumber) – единый номер (на несколько линий). Абонент услуги может задавать, какие вызовы, с какой линией соединять.
11) ODR (OriginDependentRouting) – позволяет абоненту услуги принять или отклонить вызов в зависимости от географического адреса вызова.
12) OCS (OriginatingCallScreening) – высвечивает на индикаторе номер входящего вызова, если он включен в заданный список, учитывая при этом географический адрес А-номера, время суток и т.п.
13) PRMC (PremiumCharging) – передача части оплаты за разговор вызываемому пользователю.
14) REVC (ReverseCharging) – оплата за счет вызываемого пользователя.
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-CCFCCF-CCFCCF-SRFSSF-SCFSCF-SRFSCF-SDFSMF-SCF | НIJК L М | SMF-SDFSMF-SRFSMF-SMAFSMF-SCEFSSF-CCFSMF-SSF |
Для CS‑1 определены только три из приведенных на рис. 1.6 связей, а именно D, Е и F. Возможности управления требуются только для первых шести из приведенного списка функциональных связей (т.е. для связей А, В, С, D. E и F). Функциональная связь в некоторой опорной точке может предусматривать один или несколько классов управления. Любое сочетание функциональной связи и класса управления называется управляющей связью. Управляющая связь обозначается строкой вида <буква>.<цифра> [4, 11], где <буква> обозначает функциональную связь, а <цифра> – класс управления. Определено четыре класса управления: