Организация интеллектуальной сети в г. Кокшетау на базе платформы оборудования Alcatel S12 (стр. 8 из 30)

Как указывалось ранее, архитектура ИС описывается шестью основными функциональными узлами: SCP, SSP, SMP, SCEP, SDP и IP. Различная комбинация этих функций предопределяет разные варианты построения ИС, начиная от централизованной архитектуры - ServiceNode (SN) - «узел услуг» - до распределенной - «классической» (рисунок 4.8).

Рисунок 4.8 - «Классическая» архитектура ИС

Первый вариант - полномасштабное классическое решение в виде отдельных архитектурных элементов (рисунок 4.8):

- узел SSP - коммутатор ТфОП, оснащенный обратной связью с подключенным к нему компьютером;

- узел SCP, управляющий логикой предоставления услуг;

- узел SMP, предназначенный для ввода новых услуг и корректировки старых, содержащий данные обо всех оказываемых услугах, а также оригиналы всех программ обслуживания;

- среда создания услуг SCEP;

- интеллектуальная периферия IP, которая обеспечивает процесс предоставления услуг специализированными ресурсами (объявления, речевые подсказки и пр.);

- БД услуг SDP, хранящая данные, используемые программами логики услуг [7].

«Полная» или так называемая «классическая» архитектура ИС для первого набора услуг CS-1 предназначена для использования в больших или средних сетях с высоким трафиком. Она способна обеспечить на нынешнем этапе развития практически все требования, как операторов, так и будущих пользователей. Но эта система достаточно дорогая. Поэтому компании, которых интересует, прежде всего, дешевизна и компании, которые хотят сначала оценить эффективность от внедрения новых услуг, часто выбирают другие варианты.

К одной из таких конфигураций относится вариант реализации ИС на базе узла услуг SN (рисунок 4.9), совмещающий в себе все необходимые функции ИС (SSP, SCP и IP) на единой платформе и являющийся независимым и полностью автономным сетевым элементом. Узлы услуг подключаются к сети связи по существующим системам сигнализации. Таким образом, практически все речевые соединения проходят через узел SN. Внимание должно быть обращено на наличие открытых интерфейсов, соответствующих национальным спецификациям, которые позволяют при росте трафика осуществить безболезненный переход от SN к более производительным конфигурациям. Общим требованием к базовой сети является то, что при установке SN сервис-провайдер должен обеспечить поддержку системы сигнализации ОКС №7, которая связывает все узлы «классической» ИС со всеми АТС телефонной сети. Напротив, узлы типа SN обычно могут работать с ТфОП по цифровым потокам, принятым в данной стране. И это очень важно для Казахстана, где в региональных телефонных сетях ОКС №7 не всегда поддерживается. Кроме того, для передачи абонентами ИС дополнительной информации (например, номера телефонной карты) в качестве абонентских терминалов, как правило, используются ТА с тональным режимом набора номера. Однако в странах, где принят преимущественно декадный способ набора номера, развитие услуг сдерживается из-за необходимости замены парка ТА. Если даже разом заменить все аналоговые АТС на цифровые, то вряд ли удастся заставить всех абонентов заменить свои ТА, поэтому несколько теряется смысл введения ИС. Построение ИС с узлом типа SN позволяет решить проблему за счет более гибкой реализации функции узла SSP [7].

Следующей конфигурацией ИС, которую целесообразно рассмотреть, является архитектура с вынесенными из узла услуг функциями SSP(рисунок 4.10). Такое построение ИС позволит обеспечить обработку большего трафика и является хорошим решением по внедрению услуг ИС для тех операторов, которые имеют на своей сети станции с функциями SSP, обладающие протоколом INAP-R.

Здесь функции коммутации и управления вызовами выполняются станциями, а их взаимодействие с платформой ИС осуществляется по протоколу INAP. Такая архитектура выгодно отличается от структуры узла услуг экономией емкости коммутационного поля и числа речевых каналов при предоставлении услуг ИС. Она способна поддерживать большой пакет услуг без каких-либо заметных ограничений [7].

Рисунок 4.9 - Конфигурация ИС на базе узла услуг SN

Рисунок 4.10 - Архитектура ИС с вынесенными из платформы функциями SSP

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

Функции контроля и административного управления ИС располагаются на единой платформе, а функции коммутации и управления вызовами выполняются в станциях. Специальные ресурсы обеспечиваются внешней интеллектуальной периферией IP или в ограниченном объеме могут предоставляться системами коммутации. В этом случае при росте трафика, числа абонентов или развитии услуг и необходимости перехода к более мощной системе не требуется каких-либо модификаций в спецификациях услуг ИС или в данных абонентов услуг.

Рисунок 4.11 - Архитектура ИС с вынесенными из платформы функциями SSP и IP

На первом этапе внедрения ИС целесообразно работать только с одним поставщиком оборудования. Поставщики программно-аппаратных средств ИС предлагают на рынке досконально проработанные алгоритмы предоставления услуг. Они облегчают изучение особенностей ИС и способствуют более быстрому внедрению новых услуг [12].

Сеть ИС ГТС целесообразно развивать поэтапно: от варианта наложенной сети с SSP, интегрированными в УСС, до полномасштабной реализации ИС с SSP на уровне оконечных цифровых АТС, позволяющей оптимально перераспределять трафик вызовов ИС и расширять перечень предоставляемых клиентам МГТС услуг, начиная от сравнительно небольшого их числа, рекомендуемого для первого этапа внедрения в Республике Казахстан, и заканчивая полным набором возможностей CS-1. Для г.Кокшетау, где сеть полностью цифровая доступна полномасштабная реализация ИС с SSP.

Основные преимущества ИС станут очевидными в процессе реализации возможностей CS-2, которые, кроме поддержки пользователей подвижной связи, будут способны обеспечить реальное взаимодействие между различными сетями по предоставлению услуг ИС.

4.5 Программное обеспечение ИС и создание интеллектуальных услуг

4.5.1 Создание услуг и испытательная среда для ИС

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

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

Другими словами, процесс создания услуги состоит из двух этапов: на первом этапе элементарные блоки необходимо соединить в цепь, образовав программный блок, реализующий какую-либо функцию услуги. На втором этапе следует объединение полученных блоков в услугу [6].

Для подтверждения работы услуги необходимо сначала верифицировать действие отдельных блоков услуг, а затем - действие самой услуги. Логическая проверка структуры услуги и составляющих ее блоков обеспечивается программным обеспечением SCEP. Однако этот уровень проверки не гарантирует корректности поведения каждого функционального объекта (FE) и физического объекта (РЕ), участвующего в процессе предоставления услуги, в результате чего непосредственное внедрение услуги в коммерческую сеть может быть сопряжено с риском. Для исключения такого риска необходима среда более высокого уровня, обеспечивающая моделирование работы отдельных функциональных и физических объектов [7].

4.5.2 Программное обеспечение ИС

Обычно интеллектуальные сети строятся на базе UNIX-систем, как наиболее адаптивных для сетевого взаимодействия. Кроме того, UNIX-системы обладают очень высокой степенью надежности и устойчивой защитой, что очень важно для ИС. Структура программного обеспечения SCPAlcatel 1425 приведена на рисунке 4.12. В его основе лежит многозадачная операционная система UNIX. Ядро программного обеспечения образуют операционная система, пользовательский интерфейс GUI, система управления файлами FMS и стеки протоколов ОКС-7 (для связи с SSP), Х.25 и TCP/IP (для связи с SMS). Над ядром находятся система управления реляционной базой данных ORACLE, которая содержит административные, постоянные и динамические данные, а также интерпретатор логики услуг SLI. Самый верхний уровень программного обеспечения образуют программы реализации логики услуг SLR [13].

ПО имеет высокий коэффициент готовности, возможность наращивания памяти процессоров в рабочем состоянии, коррекции без значительного снижения готовности, высокую производительность обработки вызовов и очень короткое время реакции. В результате, SCP обеспечивает устойчивую работу в сочетании со средствами обработки, ориентированными на транзакции, которые могут обработать большой объем внешних сообщений с минимальной задержкой.

Все программное обеспечение условно разделяется на слои.

Самый нижний уровень, собственно операционная система UNIX, предназначен для управления системными ресурсами (такими как процессор, жесткие диски и т.д). OMNI-платформа осуществляет функции связи с SSP.

Реализованные на втором уровне функции по администрированию баз данных и функциональных библиотек представляют базовые блоки обмена и управления данными, обработки вызовов.