Международный опыт развития интеллектуальных сетей показывает, что, несмотря на разработанные стандарты и очевидные преимущества технологии ИС, внедрение последней в практику многих стран, например, таких как Россия, происходит, не так быстро, как хотелось бы [25]. Это обусловлено проблемами экономической эффективности и техническим состоянием сетей связи, на базе которых реализуется технология ИС.
Как указывалось ранее, архитектура ИС описывается шестью основными функциональными узлами: SCP, SSP, SMP, SCEP, SDP и IP. Различная комбинация этих функций предопределяет разные варианты построения ИС, начиная от централизованной архитектуры - Service Node (SN) - «узел услуг» - до распределенной -«классической» (рис. 11.1). Решения по строительству ИС для каждого оператора должны быть сугубо индивидуальными и учитывать местные факторы такие как емкость сети, тип уже установленного оборудования, прогнозируемый трафик, планируемые услуги, экономическое состояние региона и др. Учитывая тот факт, что платформы ИС ведущих фирм-поставщиков обладают большим диапазоном производительности (обработка от 360 попыток вызовов ЧНН до нескольких миллионов), на первый план для операторов выходит задача обеспечения плавного роста мощности внедряемого оборудования без кардинальных изменений на сети. Желательно, чтобы при таком развитии расширялось только аппаратное обеспечение (объем памяти, количество серверов и т.п.) без изменения ПО, что позволит повторно использовать уже закупленные элементы в новой конфигурации. Успех при таком эволюционном пути развития средств ИС может принести только хорошо продуманный процесс перехода от одной конфигурации к другой.
Первый вариант - полномасштабное классическое решение в виде отдельных архитектурных элементов (рис. 11.1):
• узел SSP - коммутатор ТфОП, оснащенный обратной связью с подключенным к нему компьютером;
• узел SCP, управляющий логикой предоставления услуг;
• узел SMP, предназначенный для ввода новых услуг и корректировки старых, содержащий данные обо всех оказываемых услугах, а также оригиналы всех программ обслуживания;
• среда создания услуг SCEP;
• интеллектуальная периферия IP, которая обеспечивает процесс предоставления услуг специализированными ресурсами (объявления, речевые подсказки и пр.);
• БД услуг SDP, хранящая данные, используемые программами логики услуг.
Рис. 11.1. «Классическая» архитектура ИС
«Полная» или так называемая «классическая» архитектура ИС для первого набора услуг С8-1 предназначена для использования в больших или средних сетях с высоким трафиком. Она способна обеспечить на нынешнем этапе развития практически все требования, как операторов, так и будущих пользователей. Но эта система достаточно дорогая. Поэтому компании, которых интересует, прежде всего, дешевизна и компании, которые хотят сначала оценить эффективность от внедрения новых услуг, часто выбирают другие варианты.
К одной из таких конфигураций относится вариант реализации ИС на базе узла услуг SN (рис. 11.2), совмещающий в себе все необходимые функции ИС (ББР, БСР и 1Р) на единой платформе и являющийся независимым и полностью автономным сетевым элементом. Узлы услуг подключаются к сети связи по существующим системам сигнализации. Таким образом, практически все речевые соединения проходят через узел ЯТЧ. Внимание операторов должно быть обращено на наличие открытых интерфейсов, соответствующих национальным спецификациям, которые позволяют при росте трафика осуществить безболезненный переход от к более производительным конфигурациям. Общим требованием к базовой сети является то, что при установке ЯЫ сервис-провайдер должен обеспечить поддержку системы сигнализации ОКС №7, которая связывает все узлы «классической» ИС со всеми АТС телефонной сети. Напротив, узлы типа обычно могут работать с ТфОП по цифровым потокам, принятым в данной стране. И это очень важно для России, где в региональных телефонных сетях ОКС №7 не всегда поддерживается. Кроме того, для передачи абонентами ИС дополнительной информации (например, номера телефонной карты) в качестве абонентских терминалов, как правило, используются ТА с тональным режимом набора номера. Однако в странах, где принят преимущественно декадный способ набора номера, развитие услуг сдерживается из-за необходимости замены парка ТА. Если даже разом заменить все аналоговые АТС на цифровые, то вряд ли удастся заставить всех абонентов заменить свои ТА, поэтому несколько теряется смысл введения ИС. Построение ИС с узлом типа позволяет решить проблему за счет более гибкой реализации функции узла 88Р.
Рис. 11.2. Конфигурация ИС на базе узла услуг К преимуществам использования SN можно отнести:
• отсутствие необходимости в адаптации окружающей сети к внедрению услуг ИС, т.е. введение функции SSP в станции и организации их связи с платформой по INAP-R;
• возможности легкой модернизации логики услуг и создания новых услуг без внесения изменений в интерфейсы взаимодействующих объектов за счет сосредоточения функций SSP и SCP в одном узле;
• быстрое внедрение услуг;
• создание услуг в режиме on-line;
• наличие мощных инструментов административного управления;
• защиту стартовых инвестиций в ИС на всех уровнях.
Среди недостатков SN следует отметить:
• достаточно низкую производительность;
• ограниченный набор реализуемых услуг;
• неэффективное использование емкости коммутационного поля (при соединении пользователя с абонентом услуги в SN задействуется в два раза больше точек коммутации, чем при «классической» архитектуре);
• возрастание вероятности внутренних блокировок при увеличении трафика.
На рынке узлы услуг предлагают фирмы Alcatel, Siemens, Ericsson, Nortel и др. Следующей конфигурацией ИС, которую целесообразно рассмотреть, является архитектура с вынесенными из узла услуг функциями SSP (рис. 11.3). Такое построение ИС позволит обеспечить обработку большего трафика и является хорошим решением по внедрению услуг ИС для тех операторов, которые имеют на своей сети станции с функциями SSP, обладающие протоколом INAP-R.
Рис. 11.3. Архитектура ИС с вынесенными из платформы функциями SSP
Здесь функции коммутации и управления вызовами выполняются станциями, а их взаимодействие с платформой ИС осуществляется по протоколу IN АР. Такая архитектура выгодно отличается от структуры узла услуг экономией емкости коммутационного поля и числа речевых каналов при предоставлении услуг ИС. Она способна поддерживать большой пакет услуг без каких-либо заметных ограничений.
Достаточно простым решением для внедрения таких услуг ИС, где отсутствует необходимость предоставления речевых уведомлений или существуют другие возможности их реализации, а ожидаемый трафик оценивается как средний, является конфигурация с вынесением функций IP из платформы (рис. 11.4).
Рис. 11.4. Архитектура ИС с вынесенными из платформы функциями ЭЭР и 1Р
Функции контроля и административного управления ИС располагаются на единой платформе, а функции коммутации и управления вызовами выполняются в станциях. Специальные ресурсы обеспечиваются внешней интеллектуальной периферией 1Р или в ограниченном объеме могут предоставляться системами коммутации. В этом случае при росте трафика, числа абонентов или развитии услуг и необходимости перехода к более мощной системе не требуется каких-либо модификаций в спецификациях услуг ИС или в данных абонентов услуг.
На первом этапе внедрения ИС целесообразно работать только с одним поставщиком оборудования. Поставщики программно-аппаратных средств ИС предлагают на рынке досконально проработанные алгоритмы предоставления услуг. Они облегчают изучение особенностей ИС и способствуют более быстрому внедрению новых услуг.
⇐Конвергенция интеллектуальных и мобильных сетей | Интеллектуальные сети связи | Этапы внедрения средств ис⇒