Лекция: Билет 13 вопрос 1

Дополнительные услуги инфокоммуникационных сетей. Назначение. Перечень.

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

В настоящее время известно несколько концепций, позволяющих оператору предоставлять своим абонентам дополнительные услуги, к ним относятся CTI (системы компьютерной телефонии) и IN (интеллектуальные сети).

Компьютерная телефония, как процесс интеграции внешних автономных или находящихся в составе сети компьютерных систем с телефонной сетью и узлами коммутации, зародилась в конце 60-х гг., а в середине 70-х у инженеров BellLabs возникла идея интеллектуальных сетей. С того времени эти два направления предоставления услуг постоянно развиваются и широко применяются в мире телекоммуникаций.

В начале 90-х гг. возникла необходимость в технологии, которая реализовала бы единые средства и способы управления различными сетями и позволила использовать уже существующие и вновь разрабатываемые средства связи. Был сформирован консорциум ParlayGroup(1998), занимающийся созданием спецификаций открытого API (интерфейса прикладного программирования), позволяющего управлять сетевыми ресурсами и получать доступ к сетевой информации.

Кроме этого консорциума, разработкой подобных технологий занимались и другие организации, а с созданием спецификаций Parlay API версии 2.1 (2001), ETSI, 3GPP и ParlayGroupобъединили свои усилия, в результате чего были созданы полностью согласованные спецификации Parlay 3.0, ETSI 1.0 и 3GPP 4.2.

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

Серверы, на которых находятся программы приложений (услуг), и сеть, через которую абоненту предоставляется услуга, могут принадлежать различным операторам. Их можно определить как оператор (провайдер) услуг и сетевой оператор.Именно эта концепция и называется OSA (рис. 2).

Кроме ParlayGroup, работы в этом направлении ведутся также группой компаний во главе с SunMicrosystems, их разработка получила название JAIN (JavaAdvancedIntelligentNetwork).

Спецификации JAIN более широкие, они охватывают интерфейсы, не рассматриваемые в спецификациях Parlay. Кроме того, JAIN – это попытка практической реализации концепции OSA, спецификации же Parlay API создавались независящими от технологий их реализации. Технология JAIN ServiceProvider API (SPA) позиционируется как Java-реализация Parlay API, но изначально основанная на спецификациях Parlay.

Разделение сети, построенной с применением технологий OSA в области управления между различными операторами, показана на рис. 3.

Создатели технологии и разработчики оборудования утверждают, что применение концепции OSA принесет выгоду всем сторонам телекоммуникационного рынка:

• сетевые операторы получат рост трафика, как следствие ввода новых услуг, взаимодействие с операторами услуг станет проще;
• применение Parlay API позволит операторам услуг предоставлять пользователям новые, ранее не существовавшие возможности;
• станет легче создавать комплексные услуги, использующие ресурсы различных сетей;
• меньше материальных затрат потребуется для организации предоставления услуг, уменьшится время, необходимое для ввода востребованных услуг в эксплуатацию;
• разработка приложений будет проще и доступней большему количеству компаний;
• все перечисленное пойдет на благо конечного пользователя.

Теперь обратим внимание на основные характеристики и особенности Parlay API.

Позволяя серверам приложений (услуг) управлять сетью извне, API обеспечивает безопасность сети, что достигается аутентификацией приложений, применением межсетевых экранов.

По сравнению с версией 2.1, версия 3.0 обладает возможностями для получения информации о терминале пользователя, работы с голосовой почтой и E-mail, взимания оплаты с конечных пользователей и др., но при этом отсутствует совместимость версий. Данный недостаток должен быть устранен в дальнейшем развитии Parlay.

Как уже говорилось, серверы приложений могут находиться вне области сетевого оператора. Это обеспечивается с помощью технологий построения распределенных информационных систем, таких как CORBA или DCOM. Parlay – объектно-ориентированный API, CORBA (DCOM) позволяет вызывать методы у объектов, находящихся в сети где угодно, как если бы все они были локальными объектами.

Тем, кто имеет представление о идее Softswitch концепция Parlay/OSA должна показаться знакомой. Действительно, если рассматривать Softswitch как универсальное устройство управления различными сетями, то он, в свою очередь, может управляться серверами приложений через Parlay API (рис. 4).

В документах ETSI, касающихся OSA, говорится: “Спецификации OSA определяют архитектуру, позволяющую … использовать функциональность (возможности) сети через открытые стандартные интерфейсы. Функциональность (возможности) сети представляется как SCF (ServiceCapabilityFeature или Службы Parlay). OSA Framework (ядро или служебный интерфейс) является основным компонентом для обеспечения работы приложений и служб Parlay. Концепция OSA определяет набор SCF”. При этом спецификации не определяют преобразование методов (программных функций) Parlay API в сообщения протоколов INAP, CAP и др.

Интерфейс 1 обеспечивает основные механизмы взаимодействия приложений с Framework, таких как аутентификация приложения, уведомление приложения о существующих SCF и т. п.

Интерфейс 2 позволяет приложению использовать конкретные возможности сетей.

Интерфейс 3 служит для обеспечения возможности динамического подключения новых служб Parlay (SCF). В спецификациях OSA сказано, что это необходимо для предоставления служб Parlay (SCF) различными операторами.

Под интерфейсами понимаются наборы классов данного API, содержащие различные методы (программные функции).

Интерфейсы реализуются определенным функциональным элементом сети, называемым ServiceCapabilityServer (SCS) – сервер обеспечения возможности реализации услуг (в литературе его могут называть gateway).

В свою очередь, приложения располагаются на так называемых серверах приложений – ApplicationServer (AS), соединенных с SCS через IP-сеть (здесь же может применяться и межсетевой экран).