Интеллектуальная сеть (IN)

Первая дополнительная услуга телефонной сети общего пользо­вания, вышедшая за пределы одной АТС и опирающаяся на исполь­зование сетевой базы данных - связь по сервисной телефонной кар­те - была введена в США в 1980 году. Вскоре после этого там же появилась целая серия дополнительных услуг для абонентов дело­вого сектора под общим названием «служба входящей междугород­ной телефонной связи» INWATS (Inward Wide Area Telecommunications Service) со многими новыми функциональными возможностями.

Например, абонент, который набрал начинающийся с '800' номер какой-либо службы или компании, мог быть соединен с тем или иным офисом, выбор которого зависел от времени суток, дня недели, гео­графического положения вызывающего абонента. Сетевая база дан­ных перестала быть просто средством хранения данных. Ее функ­ции стали заключаться не только в ответах на запросы, принимае­мые от АТС, но и в передаче к АТС команд, указывающих, каким об­разом обслуживать вызов. Так возникло название узел управления услугами SCP (Service Control Point), а взаимодействующие с SCP через сеть ОКС7 коммутационные узлы и станции стали называться узлами коммутации услуг SSP(Service Switching Point). В рекомен-дациях ITU-T определены также вспомогательный узел управления (adjunct, AD), функционально эквивалентный SCP, но подключаемый к SSP не через сеть ОКС7, а непосредственно, и узел услуг (service node, SN), аналогичный AD, но выполняющий, помимо функций SCP, также и функции интеллектуальной периферии, к которым мы еще вернемся в конце параграфа. Так или иначе, в компьютерах SCP, на­ряду с базой данных, была запрограммирована и так называемая логика услуг, состоящая из сценариев, описывающих ту или иную услугу. Именно с этого исторического момента логика услуг пере­местилась за пределы АТС, что и составило суть концепции Интел­лектуальной сети (IN).

Общая архитектура IN включает в себя еще две важные системы - узел среды создания услуг SCEP и узел эксплуатационного управле­ния услугами SMP, - которые служат для программирования услуг и для рассылки программ и данных, необходимых для ихвыполнения, по логическим объектам, участвующим в процессе предоставления услуг. Детально концепция IN изложена в [48], а основные структур­ные элементы Интеллектуальной сети представлены на рис.11.2.

Рис. 11.2 Платформа Интеллектуальной сети

Для поддержки информационных потоков между узлами сети IN специфицирован прикладной протокол интеллектуальной сети INAP (Intelligent Network Application Protocol), который определяет синтак­сис и семантику вызываемых операций, назначение и порядок их обработки. Протокол INAP (российская версия INAP-R) вырос из транзакций, поддерживающих взаимодействие между АТС и базой данных через сеть ОКС; в настоящее время он базируется на при­кладном протоколе поддержки транзакций (ТСАР) из стека прото­колов системы сигнализации ОКС7.

Сегодня концепция Интеллектуальной сети представляет собой способ быстро создавать новые телекоммуникационные услуги в соответствии со специфическими для каждой из них требованиями, обеспечивая одновременную и повсеместную доступность этих ус­луг абонентам базовой телефонной сети общего пользования. Вве­денная ITU-T, концепция IN определяет архитектуру аппаратных и программных средств, реализующих специальные процедуры. Ис­полнение этих процедур обеспечивает управление коммутацией и иными действиями сети с целью «интеллектуальной» маршрути­зации, начисления платы, взаимодействия с пользователем. Первые стандарты IN, известные какСв-Ч, предусматривают довольно ши­рокие (с точки зрения ТфОП) возможности. Выпущенные в развитие концепции IN стандарты CS-2, а также перманентно находящиеся в стадии подготовки стандарты CS-3 и CS-4 потенциально могут дать гораздо более широкие возможности. И все же, главное значение IN для современных телекоммуникаций - не в списках услуг CS, а в ос­новной идее, состоящей в том, чтобы отделить логику услуг от функ­ций коммутации, построив соответствующую платформу. Эту плат­форму составляют определенным образом взаимодействующие функциональные блоки, реализуемые, в общем случае, в разных физических объектах - узлах IN. Функции коммутации выполняют узлы SSP, логика услуг размещается в узлах SCP, создается эта ло­гика в узле SCEP и распределяется по всем SCP узлом SMP. При соз­дании логики любой услуги используется набор стандартизованных независимых от услуг конструкционных блоков, что значительно уп­рощает работу программистов. Это особенно важно в связи с тем, что в условиях жесткой конкурентной борьбы оператор сети связи должен уметь предоставлять услуги, ориентированные на группы пользователей с сильно различающимися потребностями, и иметь возможность быстро создавать и развертывать эти новые услуги.

Для описания процессов, происходящих в SSP при предоставле­нии услуг, установлении соединения и обслуживании вызова вплоть до разъединения, в концепции IN используется модель базового процесса обслуживания вызова (ВСР - Basic Call Process). Модель содержит последовательность отображающих состояния этого про­цесса точек (PIC - Point in call), между которыми могут присутство­вать точки обнаружения (DP - Detection point) обращений к услугам IN или событий, которые представляют интерес с точки зрения ло­гики услуг IN. Триггерные точки обнаружения обращений куслугам -TDP (trigger detection points) - отмечают приостановку базового про­цесса ВСР для обращения к логике услуг IN, происходящую в соот­ветствии с заранее назначенным критерием. Таким критерием мо­жет быть определенное сочетание цифр в набранном абонентом номере, префикс, категория вызывающей абонентской линии и т.д. Важно отметить, что эксплуатационный персонал SSP может сам определять триггерные точки (т.е. делать их обнаруживаемыми) и на­значать критерии для обращения к IN.

Концептуальная модель IN отражает эту архитектуру в терминах плоскостей (planes). Плоскость услуг касается только описания ус­луг в плане их свойств. Глобальная функциональная плоскость (glo­bal functional plane) описывает программные блоки, не зависящие от услуг (service-independent building blocks, SIB). Распределенная функциональная плоскость (distributed functional plane) отображает элементы архитектуры, участвующие в обмене сообщениями IN, в ви­де функциональных объектов (functional entities, FE) и информаци­онных потоков (information flows, IF), которые моделируют обмен сообщениями между FE. Физическая плоскость (physical plane) опи­сывает аппаратно-программные блоки, называемые физическими объектами (physical entities, РЕ). Модель, показанная на рис. 11.3, содержит эти четыре расположенные одна над другой плоскости, дающие (каждая - со своей степенью детализации) абстрактное представление тех возможностей, которыми обладает сеть, постро­енная в соответствии с концепцией IN.

Верхняя плоскость модели - плоскость услуг - представляет ус­луги так, как они «видны» конечному пользователю. Такое представ­ление не содержит информации о способе и деталях реализации услуги в сети. Зато на этой плоскости видно, что услуги (services) компонуются из одной или из нескольких разных стандартизован­ных составляющих, каждую из которых пользователь воспринимает как одно из характерных свойств или, что то же самое, как один из атрибутов услуги (service features. SF).

На глобальной функциональной плоскости «появляется» сеть IN в виде единого функционального объекта. На этой плоскости пред­ставлены независимые от услуг конструкционные блоки (SIB - Ser­vice independent building blocks), одним из которых является SIB, реа­лизующий базовый процесс ВСР, а также точка обращения ВСР к дру­гим SIB, называемая инициирующей точкой (POI - Point Of Initiation) и точки возврата в ВСР (POR - Points Of Return). ВСР выполняет тра­диционные для коммутационной станции функции (установление соединения, разъединение, хранение оперативных данных, необхо­димых для дальнейшей обработки) и имеет возможность обращать­ся к другим процессам при обнаружении запроса услуги IN. POI пред­ставляет собой функциональный интерфейс между логикой ВСР и логикой другого процесса, который обеспечивает предоставление услуги (или одной из составляющих услуги) IN. После завершения этого другого процесса происходит возврат через другой функцио­нальный интерфейс (POR) в процесс ВСР, который продолжает ра­боту, используя данные, полученные при возврате. Необходимость в спецификации точек POI и POR вызвана тем, что одна и та же «це­почка» SIB может представлять совершенно разные услуги (или со­ставляющие услуг), смотря потому, в каких точках процесса ВСР она начинает и/или заканчивает свои действия.

Рис. 11.3 Концептуальная модель IN

Здесь уместно напомнить, что все изложенное в данном парагра­фе базируется на рекомендациях серии Q.12xy ITU-T, где индекс х указывает, является ли данная рекомендация общей (т.е. примени­мой ко всем версиям IN), или она относится к определенному набо­ру функциональных возможностей (CS). Значение 0 указывает, что данная рекомендация серии носит общий характер; другие значе­ния обозначают номер CS. К настоящему моменту опубликованы рекомендации для CS-1 и CS-2, CS-3, a CS-4 находится на стадии разработки. Индекс у обозначает тему рекомендации: 0 означает, что рекомендация является вводной к серии, а 1 обозначает прин­ципы архитектуры IN. Таким образом, рекомендация Q.1201 посвя­щена общим принципам, рекомендация Q.1211 - принципам архи­тектуры IN, относящимся к CS-1, и т.д. Значение 9 зарезервировано для руководства пользователя IN. Представленные на рис. 11.3 функ­циональные плоскости отражены в остальных значениях индекса у: 2 - рекомендации, относящиеся к плоскости услуг, 3 -к глобальной функциональной плоскости, 4 - к распределенной функциональной плоскости и 5 - к физической плоскости. Значение у=8 - это реко­мендации для прикладного протокола INAP Как и для большинства других стандартов ITU-T, региональные органы стандартизации раз­рабатывают национальные спецификации IN.

Несмотря на то, чтокаквС5-1, таки в CS-2 стандарты для IN обес­печили формализованную модель создания услуг спецификациями блоков SIB - рекомендации Q.1203 (общие аспекты), Q.1213 (CS-1) и Q.1223 (CS-2), - после CS-2 стандартизация SIB прекратилась.

Функциональная архитектура IN CS-1 и механизм активизации взаимодействия между ее элементами представлены на рис.11.4, являющимся, в определенном смысле, развитием рис.11.2 (более детально отражены подмножество стандартизованных к настояще­му моменту FE и их взаимосвязь). FE интеллектуальной сети группи­руются в соответствии с их ролью в поддержке IN: FE, участвующие в выполнении услуг, и FE, участвующие в создании услуг и управле­нии услугами.

К представленным на рис.11.4 функциональным объектам отно­сятся:

• Функциональный объект поддержки доступа (call control agent function, CCAF) содержит функции, обеспечивающие доступ пользователя к услугам IN; может рассматриваться как посредник телефонного аппарата или ISDN-терминала, с помощью которого пользователь взаимодействует с сетью.

• Функциональный объект управления связью пользователя (call control function, CCF) содержит базовые функции обработки запроса связи и управления коммутацией, включая функции установления, поддержки и разрушения соединений. Именно CCF реализует триггерные возможности, которые обсуждались выше, однако для полной их поддержки, а также для взаимодействия CCF с функциональным объектом управления услугами, требуется еще один объект, который имеет название функциональный объект коммутации услуг (service switching function, SSF). Предполага­ется, что объекты SSF и CCF физически совмещены, т.е. они не могут размещаться в разных физических объектах РЕ.

• Функциональный объект управления услугами (service control
function, SCF) содержит логику услуг и управляет действиями SSF/
CCF и других функциональных объектов.

• Функциональный объект специализированных ресурсов (specialized resource function, SRF) обеспечивает воспроизведение записанных речевых сообщений и сбор входных данных от пользователя (либо в виде сигналов DTMF, либо в виде речевых сигналов, в зависимости от используемых устройств), отвечает за организацию конференцсвязи, поддержку факсимильной связи и преобразование некоторых протоколов, а также за преобразование «текст-речь» и «речь-текст».

• Функциональный объект предоставления данных для услуг (service data function, SDF) обеспечивает доступ SCF в реальном времени к данным, требующимся для предоставления услуг IN, и проверку этих данных.

На рис.11.5 представлена модель состояний базового процес­са обслуживания вызова (BCSM) для CS-2, которая специфициро­вана в последнем из опубликованных стандартов. BCSM - это мо­дель действий CCF, необходимых для организации и поддержания связи между пользователями. BCSM моделирует состояния базо­вого процесса обслуживания и исходящих и входящих вызовов, но мы ограничимся только рисунком, относящимся к исходящему вы­зову. Основные состояния процесса в модели O_BCSM (О - outgo­ing, т.е. исходящая часть), как их видит АТС, показаны внутри пря­моугольников; их называют PIC (points in call). Кроме того, имеют­ся и другие состояния, которые называются точками обнаружения (detectionpoints, DP); на рис.11.5 они показаны квадратами. Имен­но в точках DP АТС может прервать обработку вызова путем пере­дачи сообщения к SCF. Каждая DP может быть либо задействован­ной (armed), либо не задействованной (unarmed). Внешняя логика услуг (внутри SCF) обнаруживает DP только тогда, когда та задей­ствована. DP может быть задействована либо статически (со сто­роны SMF, как результат ввода в действие атрибута услуги), либо динамически (со стороны SCF). Если DP была задействована ста­тически, она остается задействованной до тех пор, пока SMF не выведет её из этого состояния, т.е. пока предоставляется та услу­га, для которой она нужна; такая DP называется триггерной точкой обнаружения (trigger detection point, TDP). Если же DP была задей­ствована динамически, она остается в этом состоянии не дольше, чем длится обусловленное ее обнаружением взаимодействие ме­жду SCF и SSF; такая DP называется точкой обнаружения события (event detection point, EDP).

В условиях уже упоминавшейся конвергенции сетей и услуг свя­зи сохраняется ключевой принцип отделения организации новых телефонных услуг от транспортировки, составляющий основу Интел­лектуальной сети (см. рис. 11.6). Точно так же, как было только что описано, узлы коммутации услуг распознают вызовы, требующие услуг IN, и обслуживают эти вызовы, взаимодействуя с централизо­ванным узлом SCP. Наличие на рис. 11.6 элементов мобильной IN подразумевает взаимодействие протоколов INAP и ТСАР с другими протоколами ОКС7 - MAP (Mobile Applications Part), IS41 и CAMEL (Customized Applications for Mobile Network Enhanced Logic).

У читателя, который не удовлетворится этим более чем кратким описанием IN, есть возможность обратиться к книге [48]. Там отме­чены основные преимущества концепции IN в свете проблем кон­вергенции сетей: гарантированное сквозное (end-to-end) качество обслуживания (QoS), экономичное введение новых услуг через INAP или с помощью SN (Service Node) и др. Благодаря этому, по всей вероятности, именно Интеллектуальная сеть окажется тем мостом, который позволит традиционным телефонным сетям (как стационар­ным, так и мобильным) взаимодействовать с IP-сетями. Такая тен­денция эволюции Интеллектуальной сети проявляется в создании протоколов WAP (Wireless Application Protocol), RADIUS (Remote Au­thentication Dial-In User Service), LDAP (Lightweight Directory Access Protocol) и соответствующих этим протоколам технологий.

Рис. 11.5 Исходящая часть BCSM для CS-2 по Q. 1224

Рис. 11.6 Эволюция концепции IN

Имеются варианты эволюции Интеллектуальной сети, появившие­ся после того как была написана книга [48]. Весьма интересны раз­работки рабочих групп PINT/SPIRITS (SIP-скрипты и взаимодейст­вие IPSSF с SIP) и Eurescom (взаимодействие IPSSF с Н.323). Эти решения обеспечивают доступ к услугам IN пользователей IP-теле­фонии, что особенно актуально для западноевропейских стран, где были сделаны значительные вложения в оборудование Интеллекту­альных сетей. PINT и SPIRITS ориентированы на поддержку равно­правного доступа компьютерного терминала с пакетной передачей речи (PC) и обычных телефонов ТфОП или GSM ко всем услугам; оба подхода, так или иначе, ориентируются на протокол SIP. Обо всем этом мы поговорим в параграфе 11.4 этой главы.

Нельзя умолчать и о недостатках подхода IN. К ним относятся: необходимость существенных начальных инвестиций при создании Интеллектуальной сети, относительная сложность протоколов INAP и ТСАР, невостребованность целого ряда услуг из списка CS-1 (Fol­low me, например), централизация биллинга и управления услуга­ми, ограничивающая возможности выполнения этих функций конеч­ными пользователями, и некоторые другие. Разрабатываемые се­годня интеллектуальные коммутационные платформы на базе тех­нологий компьютерной телефонии третьего поколения сами явля­ются интегрированными коммутаторами и процессорами поддерж­ки услуг с начислением платы за них. Это объективно вызывает сме­щение интеллекта из традиционных узлов IN к краям сети, чему по­священ следующий параграф.