Архитектура OSA/Parlay как реализация NGN Что такое OSA/ParlayБурное развитие мобильных сетей в России и острая конкуренция между операторами сетей

требует привлечения отечественных программистов к разработке новых приложений (услуг с добавленной стоимостью VAS, Value Added Services). Сложность построения единой сети нового поколения NGN (Next Generation Network) состоит в том, что существующие сети фиксированной и мобильной связи, сети Интернета построены по различным стандартам и их программное обеспечение взаимно не переносится, что тормозит развитие рынка услуг. Это особенно актуально для мобильных сетей: построены сети разных стандартов (NMT, GSM, CDMA и др.), и ставится цель их объединения - при построении широкополосной сети UMTS (Universal Mobile Telecommunications System). Как придумать такую архитектуру сети, чтобы программное обеспечение, например, для карты предоплаты или предоставления бесплатного разговора (Услуга 800), не зависело бы от конкретного вида сети или технологии, - вот главная стратегическая проблема связистов во всем мире. Решение этой задачи призвана обеспечить концепция открытого доступа к услугам OSA (Open Service Access). Архитектура Parlay является одной из практических реализаций концепции OSA.

Как показано на рис. 1, разные сети связи имеют различные сетевые элементы: Мобильные сети GSМ включают MSC (Mobile Switching Center), а внедрение услуги

пакетной передачи GPRS потребовало введения нового узла SGSN (Serving GPRS Support Node), и эти сети используют протокол МАР (над стеком сигнализации ОКС-7) для роуминга пользователей мобильной связи и протокол САР для предоставления услуг интеллектуальной сети  ( в рамках проекта САМЕL),

Мобильные сети 3-го поколения UMTS включают, в частности, узел S-CSCF (Serving Call Session Control Function), и в качестве протокола сигнализации используется протокол SIP,

Телефонная сеть общего пользования, точнее, интеллектуальная сеть включает SSP (Service Switching Point) – коммутатор услуг в ТфОП, который использует протокол INAР.

Каждый из этих сетевых элементов выходит на шлюз (Gateway) по своему протоколу, и задача шлюза, по концепции OSA/Parlay, состоит в том, чтобы свести все протоколы к единым интерфейсам API (Applied Programming Interface). Тогда приложения можно будет писать без учета особенностей нижележащих сетей, если только строго придерживаться интерфейсов API.

Рис. 1. Архитектура OSA/Parlay

Архитектура OSA/Parlay является одним из перспективных решений NGN:

1)      OSA/Parlay-шлюз объединяет как новые сети коммутации пакетов, которые строятся по стандартам 3GPP, так и существующие сети коммутации каналов, что отвечает требованиям эволюции сетей к NGN,

2)      Наличие единых открытых интерфейсов OSA/Parlay API обеспечивает разработку новых приложений по принципу «единые интерфейсы – единая семья программистов».

2 Международные стандарты OSA/Parlay Разработка архитектуры Parlay началась в 1998 г. - по инициативе British Telecom, Microsoft,

Nortel Networks, Siemens и Ulticom, к ним присоединились Cisco, Ericsson, IBM, Lucent и др. и сейчас число участников Parlay–группы превышает 60. В 2001 г. инициативу Parlay-группы поддержали международные организации: Европейский институт стандартизации телекоммуникаций ETSI и Консорциум мобильных сетей 3-го поколения 3GPP (рис. 2). Версия Parlay 3.1 согласована с документами ETSI и 4-ой версией стандартов 3GPP (Release 4). На базе версии Parlay 4.0 разрабатывается следующая версия стандартов 3GPP (Release 5).  

Кроме того, Parlay-группа сотрудничает с международным сообществом JAIN, которое разрабатывает открытые интерфейсы на базе языка Java: спецификации Parlay 2.1 взяты за основу модели вызова JAIN Call Control. В последнее время семейство разработчиков Parlay дополнилось еще одним весьма активным членом – OMA (Open Mobile Alliance), которое создано в июне 2002 г.

Рис. 2. Спецификации Parlay разрабатываются совместными усилиями Parlay-группы, Европейского института стандартизации телекоммуникаций ETSI и Консорциума мобильных сетей 3-го

поколения 3GPP

Как устроен Parlay-шлюз Открытые интерфейсы Parlay являются объектно-ориентированными программами и состоят из

множества классов. Основу архитектуры Parlay составляют три блока (рис. 3): Parlay-ядро (Framework), Сервисные компоненты и Приложения.

 На рис. 3 показаны 9 сервисных компонентов (согласно версии Parlay 3.х), в том числе: контроль вызова (Call Control), взаимодействие с пользователем (User Interaction, UI), свойства мобильности (Mobility), управление расчетами (Account Management) и др. В новейших спецификациях Parlay добавлены еще два сервисных компонента – Policy Management и Presence and Availability Management. Заметим, что приложения, которые разрабатываются программистами, обычно написаны на Java или С++, а доступная им функциональность определена сервисными компонентами.

Рис. 3.Архитектура Parlay-шлюза

Назовем основные функции Parlay-ядра: аутентификация приложения (в соответствии с предварительно заключенным

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

соглашение об обслуживании, обеспечение доступа к сетевым функциям (безопасность, контекст, домен и т.д.).

ПримерНа рис. 4 приводится алгоритм услуги «Спортивные новости». Показаны 17 шагов алгоритма –

от регистрации спортивной программы с участием ядра (Framework) до получения спортивных новостей в виде сообщения USSD и расчета за услугу (с участием сервисных компонентов Account Management и Charging).

Рис. 4. «Спортивные новости» - счет (scores) футбольной игры - пользователь получает на мобильный телефон, пользуясь протоколом USSD.

Три группы Parlay-интерфейсов Открытые интерфейсы Parlay являются объектно-ориентированными программами и состоят из

множества классов. Основу архитектуры Parlay составляют три блока (рис. 5):  Parlay-остов (Framework, Fw), Системные услуги (Services) и Приложения.

Рис. 5. Схема Parlay-интерфейсов

Эти блоки общаются посредством интерфейсов. На рис. 5 указаны три группы интерфейсов (в соответствии с цифрами):

1.      интерфейсы между приложениями и Parlay-остовом. Основные функции этих интерфейсов заключаются в следующем:

аутентификация приложения (в соответствии с предварительно заключенным соглашением о доступе данного приложения),

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

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

связи),3.      интерфейсы между Parlay-остовом и услугами. Основная их задача состоит в регистрации

новых системных услуг.  Перечислим основные системные услуги, которыми пользуются Parlay-приложения (с

разрешения Parlay-остова): - контроль вызова (Call Control), - взаимодействие с пользователем (User Interaction, UI),-  свойства мобильности (Mobility), - биллинг, - управление расчетами (Account Management) и др.

О безопасности Parlay-платформыНа рис. 6 указана «граница безопасности сети», которая отделяет безопасную область (trusted

environment), куда входят операторы сетей связи, от внешней, небезопасной области (untrusted environment), куда входят открытые сети передачи данных и где расположены сторонние разработчики.

 В задачи Parlay-шлюза входит охрана безопасности сетей связи от несанкционированного доступа.

Рис. 6. «Граница безопасности сети» отделяет операторов сетей связи от открытых сетей передачи данных, где расположены сторонние разработчики.

Мобильные сети 3G и Parlay-шлюзы Мобильные операторы Европы вложили огромные деньги в приобретении лицензий на право

построения мобильных сетей 3-го поколения 3G. И сейчас стало очевидно, что эти деньги можно вернуть только при условии, если пользователям сети удастся предложить достаточно много приложений и услуг добавленной стоимости. Если, кроме традиционных голосовых услуг, удастся предложить мультимедийные услуги (контент), мобильную коммерцию, развлечения и т.д. А это, в свою очередь, требует привлечения к разработке приложений достаточно широкого круга сторонних программистов.

Ответом на вызов текущего момента является инициатива разработки открытого доступа к услугам OSA (Open Service Access), что воплотилось в создании новой международной организации «Parlay-группа». “ONE API for ONE developer community”, - это крылатое выражение объясняет оптимизм, с которым работает «Joint API Group», т.е. Объединенная API-группа. Она пытается учесть интересы пяти заинтересованных международных организаций (рис. 7):

Parlay-группа, Международный консорциум 3GPP (в рамках проектов UMTS и OSA), Институт стандартизации ETSI (в рамках проектов NGN и OSA), JAIN, ITU-T.

Рис. 7. Схема взаимодействия Объединенной API-группы (Joint API Group) с международными организациями: Parlay-группа, Международный консорциум 3GPP, Институт стандартизации ETSI, JAIN и ITU-T.

На рис. 7 указан основной алгоритм работы «Joint API Group»:1) Требования к интерфейсам пишут участники Joint API Group, т.е. представители упомянутых

пяти организаций,2) Интерфейсы API разрабатываются с учетом требований участников Joint API Group,3) Результаты получают все участники Joint API Group.Открытые интерфейсы API неразрывно связаны с технологией программирования. В настоящее

время объединяющим является язык UML (Unified Modeling Language). На базе модели UML каждый из членов Joint API Group генерирует свой формат документов (см. http://docbox.etsi.org/tech-org/span/open/span12/UML/). Разработаны реализации интерфейсов API для трех технологий (рис. 8):

OMG IDL для CORBA, •WSDL для HTTP/SOAP и •переход на Java OSA APIs из JAIN SPA.

Рис. 8. Реализация интерфейсов API для трех технологий: OMG IDL (для CORBA), WSDL (для HTTP/SOAP) и JAIN SPA (в виде Java OSA APIs)

Конечно, следует отметить, что концепция Parlay в частности и деятельность Joint API Group вообще дают ответ только на часть задач, стоящих перед консорциумом 3GPP (рис. 9), а именно:

В части базовых сетей – это только открытый доступ OSA, В части услуг и сетевых аспектов: Требования к предоставлению услуг и Архитектура построения приложений и услуг.

Рис. 9. Место “Joint API Group” в концепции 3GPP

Как зарабатывать на Parlay-приложенияхБорьба за контент-услугиВ настоящее время в мире происходят резкие изменения портфеля доходов телефонного

оператора. Ожидается резкое падение относительной доли доходов операторов связи за передачу речевого трафика (при незначительном росте абсолютного значения этих доходов). Зато планируется резкий рост абсолютных доходов за дополнительные услуги связи: уже в ближайшие годы сформируется новый рынок услуг контента (информационных услуг) и к 2005 г. в странах Европы он

может составить 30-40% от общего объема доходов телекоммуникационного сектора. Этот прогноз крайне актуален для российских операторов связи, а также для программистов, так как указывает на перспективную область применения труда здесь же в России – в условиях бурного роста мобильной связи и Интернета.

Как освоить рынок информационных услуг – вот вопрос. На этом рынке телефонные операторы имеют очень серьезных конкурентов в лице интернет-компаний. И собственными силами этот рынок вряд ли удастся удержать. Придется сотрудничать. И успех в этой области будет зависеть от наличия открытых интерфейсов API (Applied Programming Interface), что позволит привлечь к разработке приложений сторонние организации и совместными усилиями осваивать прибыльный рынок приложений. В частности, успех Федеральной программы «Электронная Россия» будет зависеть от массовой инициативы, от умения вовлечь в работу отечественных программистов на местах.

Зарождается индустрия информационных услуг (контента). На примере мобильного интернета  перечислим участников рынка услуг сегодня и в ближайшем будущем (Таблица 1):

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

2) В ближайшем будущем на рынке мобильной связи появятся новые участники, и число участников рынка услуг существенно увеличиваеися (пять новых участников выделены курсивом).

Таблица 1. Как образуется стоимость услуги мобильного ИнтернетаСегодня ЗавтраРазработка технологии мобильной связи,

Разработка оборудования и инфраструктуры сети,

Операторы мобильной связи,

Провайдеры мобильных услуг,

Производство мобильных трубок,

Пользователи (абоненты).

Разработка технологии мобильной связи,

Разработка оборудования и инфраструктуры сети,

Разработка платформы приложений,

Разработка приложений,

Провайдеры контента,

Агрегаторы контента,

Провайдеры мобильных порталов,

Операторы мобильной связи,

Провайдеры мобильных услуг,

Производство мобильных трубок,

Пользователи (абоненты).

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

Три бизнес-модели

Рис. 1. Три бизнес-модели взаимоотношений между оператором сети и провайдером услуг На рис. 1 показаны три бизнес-модели - как делить доходы от продажи контента:  Модель (а) соответствует минимальному участию оператора сети  в предоставлении услуг.

Провайдер услуг общается с пользователем напрямую. Оператор по существу остается в стороне, он только обеспечивает доступ к сети и услугам (обеспечивает  «битовую трубу» - Bit-Pipe). Кроме того, может собирать плату за услуги и передавать ее провайдеру.

Третья модель (в) соответствует максимальному участию оператора связи: он сам предоставляет контент-услуги, арендуя их у провайдера услуг.

Во второй модели (б) оператор предоставляет услуги от имени провайдера услуг. Тем самым он активно участвует в предоставлении услуг, но не берет на себя полную ответственность.

Мировой опыт показывает, что модель (б) является наиболее жизнеспособной. Эту модель распределения доходов иллюстрирует рис. 2. Плата за услугу 2,25 долл. делится между оператором сети (0,90 долл.), владельцем портала (0,15 долл.) и провайдером контента (1,20 долл.), т.е. оператор сети удерживает 40% доходов, а 60% передает партнерам: владельцу портала (7%) и провайдеру контента (53%).

Рис. 2. Пример распределения доходов от продажи контента

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

Опыт NTT DoCoMo (Япония)Опыт японской компании NTT DoCoMo, точнее небывалый успех проекта “i-mode”, пристально

изучается операторами связи и контент-провайдерами во всем мире.С самого начала проекта  мененджеры компании DoCoMo упростили процесс привлечения и

лицензирования контент-провайдеров и, самое главное, оставляли себе только 9% платы за контент (для покрытия административных расходов), остальные 91% возвращая контент-провайдерам. Это вызвало небывалую активность: в 2001 году DoCoMo в рамках проекта “i-mode” имела 40 тысяч мобильных приложений, 28 млн. пользователей.

Рис. 3. За что платит пользователь “i-mode”

Более подробную схему формирования доходов от продажи контента показывает рис. 3. Пользователь платит:

абонетскую плату 3 долл/мес, за трафик передачи данных 0,3 цента за пакет в 128 байтов, за контент-услуги по проекту “i-mode” в зависимости от заказанной услуги (см. Табл. 2), за контент-услуги вне проекта “i-mode”.

Таблица 2. Плата за услуги “i-mode”.Услуги “i-mode” Цена в долл. СШАМультфильмы ДиснеяБизнес-новости NikkeiМелодии (вместо вызывного сигнала)Сигналы Pokemolo-JoyПоиск в словареГоночная игра MiracleGPГороскопы

0,83/месБесплатно0,83/мес2,48/мес0,41/мес2,48/мес1,40/мес

Информационные услуги/банкинг 0,17 – 0,25 за обращение

Какие уроки следует извлечь из японского опыта? Привлекательные тарифи для контент-провайдеров и привлекательные схемы взаиморасчетов оказались решающими для успеха, это явилось первым условием. Второе условие – услуги поставлялись по сети передачи данных, которая всегда доступна. Оплата определяется только переданными килобитами + месячная плата (см. Таблицу 1). Несмотря на весьма скудные ресурсы сети передачи данных – всего 9,6 Кбит/с, компания DoCoMo привлекла сотни контент-провайдеров. Это показывает, что для развития рынка услуг не следует ждать появления пропускной способности 64 Кбит/с или построения сетей 3G.

Telenor Mobile (Норвегия)Telenor Mobile – один из первых европейских операторов, которые учли опыт  DoCoMo.

Компания Telenor Mobile ввела стандартизованную схему разделения доходов, что позволило привлечь лучших контент-провайдеров. В 2001 году их было более 100. Залогом успеха послужили привлекательные тарифы: Telenor Mobile возвращает контент-провайдерам от 45,5% до 77% платы за услугу. На рис. 4 показана схема построения системы доступа контент-провайдеров CPA (Content Provider Access). В ней используется система SMS, система позиционирования и система биллинга.

Рис. 4. Платформа CPA компании Telenor Mobile (Норвегия)

Рис. 5. Пример использования платформы CPA

На рис. 5 показан пример использования платформы CPA. Пользователь находится на отпуске и желает просмотреть любимую газету в интернет-кафе. За эту услугу провайдер газеты требует плату в 1 долл. После обращении к сайту новостей пользователь вводит номер своего мобильного телефона и получает пароль web-сайта на мобильный телефон в виде сообщения  SMS (шаги 1 – 3 на рис. 5). Он вводит этот пароль в компьютер и получает доступ к газете.  Плата в 1 долл появляется на его счету за мобильный телефон (шаги 4 – 6 на рис. 5).

T-Motion (Великобритания) Компания T- Motion (Великобритания) начала рекламу информационных услуг в августе 2001 г.

Компания платит контент-провайдерам  50% дополнительной платы за услуги. Оплата производится через ежемесячный счет или посредством кредитной карточки. Так как пользователь платит абонентскую плату (около 15 долл/мес) + по-пакетную плату за использования сети GPRS + дополнительную плату за услуги, то предлагаемая схема весьма далека от схемы японской компании DoCoMo. Таблица 3 дает представление о наборе предлагаемых информационных услуг компании T-Motion. Они разделены на две групп: бесплатные (free) и за дополнительную плату (premium).

Таблица 3. Перечень информационных услуг компании T-Motion

Parlay X: Web-сервисыКонцепция Parlay X: основная идеяПрошло всего несколько лет работы Parlay-группы, прошли первые испытания интерфейсов

Parlay. И оказалось, что концепция Parlay является слишком сложной для массового привлечения сторонних программистов, особенно в условиях повального увлечения web-услугами, широким распространением такой простой услуги как почта SMS. Изначально предполагалось, что Parlay-шлюз общается с различными сетями связи и что используются самые различные протоколы: INAP, CAMEL, SIP, MEGACO и другие. Но выяснилось, что для предоставления 80% услуг требуется лишь 20% возможностей Рarlay-шлюза. Следовательно, для подавляющего большинства программистов требование освоить весь набор Рarlay-интерфейсов является чрезмерно завышенным. По мере уменьшения разнообразия возможностей сети растет число разработчиков приложений, и это чрезвычайно важно для освоения прибыльного рынка приложений. Эти рассуждения иллюстрирует рис. 1, где показаны слева четыре набора функций сети:

1) Наибольшие возможности дает использование протоколов (INAP, CAMEL, SIP и др.), как это делается до сих пор, но при этом сообщество разработчиков является минимальным.2) Значительное упрощение дают открытые интерфейсы  API: JAIN, Parlay, OSA, а также собственные интерфейсы (Proprietary APIs).

3) Еще больше программистов разрабатывают Web-услуги, используя простые языки скриптов: XML, VXML, CPМL, WDSL.

4) Замысел Parlay X состоит в еще большем упрощении программирования Web-услуг. 

Рис. 1. По мере уменьшения разнообразия возможностей сети растет число разработчиков приложений

Первые документы по концепции Перечислим задачи, которые ставит перед Parlay-группа в части Web-услуг, точнее: рабочая группа Parlay Х. Разработчики придерживаются «Принципа поцелуя» (Игра слов “The KISS principle – Keep it simple, stupid!”) Основная цель заключается в выборе достаточно мощного, но простого набора функций телекоммуникаций, который могли бы легко освоить специалисты информационных технологий и разрабатывать новые приложения:

Каждый модуль услуг (building block) представляет абстракцию некоторого набора интерфейсов Parlay,

Возможности каждого модуля могут быть однородны (например, только контроль вызова) или неоднородны (например, мобильность и свойство присутствие – presence),

Взаимодействие между приложением и модулем услуг (т. е. Parlay X API) должно быть реализовано посредством простого обмена  XML-сообщениями,

Модули не должны содержать специфику приложений.

Рисунок 2 показывает взаимоотношение между Parlay Х Web-услугами и интерфейсами Parlay API. Приложения Parlay Х могут общаться с Parlay-шлюзом посредством системы CORBA или транспортных средств Web-услуг. В общем случае приложение Parlay Х может быть достаточно сложным и использовать все богатство свойств Parlay-шлюза. Например, приложение Parlay Х может создавать вызов по различным протоколам сигнализации (в рамках сеанса связи многих пользователей, multiparty call), раздельно создавать каждое плечо вызова (call leg).

Приложения могут быть написаны на языках C++, Java или Visual Basic. Для разработки приложений Parlay Х основным языком программирования является язык XML. В качестве транспортных средств чаше всего используются:

CORBA – универсальный объектно ориентированный протокол взаимодействия распределенных систем,

SOAP – упрощенный протокол общения распределенных объектов, основан на языке XML, используется в сочетании с протоколом HTTP.

Рис. 2. Взаимоотношение между Parlay Х Web-услугами и интерфейсами Parlay API

Архитектурная модель Web-сервисовWeb-сервисами называют приложения в Интернете, которые могут быть опубликованы,

обнаружены и запущены с помощью Интернета. Примерами Web-сервисов могут быть: Получение информации о курсе акций Прогноз погоды Резервирование авиабилетов.

В случае телефонии примером Web-сервиса может служить изменение списка дополнительных услуг самим абонентом с помощью Интернета.

Обсудим архитектурную модель Web-сервисов с точки зрения потребностей платформы Parlay Х. Web-услуга (по концепции Parlay Х) представляет собой интерфейс, который описывает набор операций, доступных (на сети Интернета или Интранета) посредством стандартного механизма передачи сообщений. Web-услуга описывается на стандартном языке XML, и это описание включает форматы сообщений, протоколы транспорта и их размещение. Заметим, что между разработчиками Parlay и Parlay Х наблюдается несовпадение терминологии. В архитектурной модели Web-услуг различают три составные части (рис. 1):

Шлюз Web-услуг – Service Provider, Приложение (заказчик Web-услуг) – Service Requestor. Реестр Web-услуг – Service Registry. В реестре заносится описание предоставляемых услуг

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

соответствует Service Registration),·        find (найти), т.е. найти заказанную услугу (в концепции Parlay это соответствует Service

Discovery),

·        bind (увязать), т.е. фиксировать использование услуги (в концепции Parlay это соответствует Service Lifecycle).

 В качестве протоколов общения между тремя составными частями архитектуры Parlay Х указаны два средства:

WSDL – основанный на XML язык описания Web-услуг, UDDI – протокол и модель данных, которые поддерживают операции publish и find.

Рис. 3. Архитектурная модель Web-услуг

Oсновой для взаимодействия между распределенными частями приложения являются вызовы удаленных процедур (RPC). Это промежуточное ПО скрывает различия между типами сетевых узлов, избавляет разработчиков от выполнения заданий нижнего уровня, например, от преобразования данных или от их побайтового упорядочивания на различных машинах. Оно размещается над операционными системами и сетевыми службами, установленными на этих хостах, и обслуживает находящиеся на более высоком уровне приложения. Первые промежуточные программные продукты, например DCE, основывались на модели процедурного программирования. Им на смену пришла объектно-ориентированная модель, реализуемая в промежуточных программных продуктах CORBA, DCOM или RMI, которые являются наиболее популярным программным обеспечением этого класса в настоящее время.

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

Поскольку веб-сервисы представляют просто еще одну парадигму для распределенных приложений, они состоят их тех же самых трех компонентов:

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

Поставщика сервисов (Service Provider), который публикует свои сервисы для сервисного агента.

Инициатора сервисного запроса (Service Requester), который запрашивает у сервисного информацию агента о том, где найти подходящего поставщика сервисов, а затем связывается с этим поставщиком.

Промежуточное программное обеспечение, упомянутое выше (CORBA, DCOM или RMI), использовалось в качестве двоичного протокола связи между частями приложения. Однако веб-сервисы

используют XML поверх протокола HTTP. Поэтому не возникает никаких проблем при работе через сетевые экраны (брандмауэры), поскольку они обычно не блокируют порт HTTP. Если вернуться к определению, можно заметить, что веб-сервисы не обязательно должны использовать только HTTP. В качестве альтернативы могут быть рассмотрены также протоколы FTP и SMTP.

На рис. 4 показан стек веб-сервисов. В основе его лежит язык расширяемой разметки XML (Extensible Markup Language). XML является общепризнанным форматом обмена данными и соответствующей им семантики. На его основе построены следующие три уровня: 

протокол доступа к простым объектам SOAP (Simple Object Access Protocol); язык определения веб-сервисов WSDL (Web Services Definition Language); универсальная интеграция поиска описаний UDDI (Universal Discovery Description Integration).

Рис. 4. Стек веб-сервисов

Сравнение Parlay и Parlay X Рисунок 1 показывает взаимоотношение между Parlay Х Web-сервисами и интерфейсами Parlay

API. Приложения Parlay Х могут общаться с Parlay-шлюзом посредством  транспортных средств CORBA или Web-сервисов. В общем случае приложение Parlay Х может быть достаточно сложным и использовать все богатство свойств Parlay-шлюза. Например, приложение Parlay Х может создавать вызов по различным протоколам сигнализации (в рамках сеанса связи многих пользователей, multiparty call), раздельно создавать каждое плечо вызова (call leg).

Приложения могут быть написаны на языках C++, Java или Visual Basic. Для разработки приложений Parlay Х основным языком программирования является XML. В качестве транспортных средств чаще всего используются CORBA и SOAP.

Рис. 5. Взаимоотношение между Parlay Х Web-сервисами и интерфейсами Parlay API

Сравним две архитектуры: Parlay и Parlay Х. На рис. 6 показано взаимодействие приложения (Application) и шлюза (Parlay/OSA Gateway) в архитектуре Parlay. Шлюз предоставляет услуги ядра (Framework) и системные услуги (Services). Приложение не имеет прямого доступа к системным услугам. На рис. 6 взаимодействие разделено на три шага:

Прежде всего, приложение общается с ядром: проходит фазу аутентификации и запрашивает требуемые системные услуги.

Ядро верифицирует приложение, согласует параметры использования этих услуг (в соответствии с соглашением Service Level Agreement), после чего сообщает ссылки (references). Эта процедура дает право приложению только на единичный сеанс связи.

Пользуясь полученными ссылками (Service references), приложение вызывает методы системных услуг и получает доступ к ресурсам сети связи (через соответствующие протоколы).

Рис. 6. Взаимодействие приложения (Application) и шлюза (Parlay/OSA Gateway) в архитектуре Parlay

Архитектура OSA/Parlay как реализация NGN Web-сервисы, как известно, действуют в режиме “запрос-ответ» (request-response). Информация

Web-сервисов ориентирована на услуги (service-oriented), а не на ресурсы сети связи (resource oriented). Поэтому, в большинстве случаев, запросы на услуги решаются в течение единичного взаимодействия и не тредуют ответа непосредственно (в жестких временных рамках). Само взаимодействие инициируется приложением, которое посылает запрос услуге.

В настоящий момент рабочей группой Parlay X осознана целесообразность наличия механизма уведомления (notification) о событиях в сети, но он пока не реализован в спецификациях Parlay X Web Services. Предполагается, что механизм уведомлений будет реализован в контексте протокола SOAP, точнее: будет определен в WSDL/SOAP.

Режим «запрос-ответ» является простым способом и доступен более широкому кругу разработчиков приложений, однако он затрудняет программирование деталей взаимодействия, не обеспечивает масштабируемость системы, которую дает асинхронный способ взаимодействия и механизм уведомлений.

Рисунок 7 иллюстрирует основное различие архитектур Parlay и Parlay Х. В левой части рисунка три основных действия в архитектуре Parlay: регистрация приложения в ядре шлюза, предоставление услуг шлюза приложению и контроля вызова. В случае Parlay Х (правая часть рисунка) взаимодействие ограничивается обменом «запрос-ответ».

Рис. 7. Различие взаимодействия между приложением и провайдером услуги в архитектурах Parlay и Parlay Х

Стандартные Parlay X Web-сервисыParlay-группа по Web-сервисам, точнее: рабочая группа Parlay Х разработала 8 базовых Web-

сервисов для телекоммуникационных применений, на основе которых можно строить другие Web-сервисы. Основная цель работы рабочая группа Parlay Х заключается в выборе достаточно мощного, но простого набора функций телекоммуникационных сетей, который могли бы легко освоить специалисты информационных технологий и разрабатывать новые приложения:

·  Каждый модуль услуг (building block) представляет абстракцию некоторого набора интерфейсов Parlay,

·  Возможности каждого модуля могут быть однородны (например, только контроль вызова – call control) или неоднородны (например, мобильность и присутствие – mobility & presence),

·  Взаимодействие между приложением и модулем услуг (т. е. Parlay X API) должно быть реализовано посредством простого обмена XML-сообщениями,

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

Таким образом, в разработке приложений Parlay X могут принять участие не только программисты (профессионально владеющие, например, языком Java), но и web-разработчики, имеющие дело с языком XML.

Спецификацией Parlay X предусмотрено 8 модулей услуг (building blocks), которыми могут воспользоваться web-разработчики:

1.      Third Party Call Control2.      Network Initiated Third Party Call Control3.      SMS4.      Multimedia Messaging5.      Payment6.      Account Management7.      User Status8.      User LocationЗаметим, что основной вклад в разработку этих спецификаций внесла ирландская компания

AePONA (из Дублина), а 5-ый модуль спецификаций «Payment» разработан международной организацией PayCircle, которая создана в январе 2002 года и включает более 30 компаний, в том числе CSG Systems, Hewlett-Packard, Oracle, Siemens, Sun Microsystems.

Подробнее о Parlay-интерфейсахНа экране мобильного телефона можно получить различные справки (рис. 1), т.е. различные

информационные услуги: об условиях на автодорогах и выборе наиболее подходящего маршрута, о погоде, курсе акций и т.п. Эти справки можно получать и в виде голосовых сообщений. Пользователь может прослушать информацию о наличии голосовой или электронной почты, прослушать ее или прочесть на экране. Этому служат технологии распознавания голоса (ASR – automatic speech recognition) и преобразования текста в речь (TTS – text to speech).

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

Рис. 1. На экране мобильного телефона можно получить различные справки

Как работает Parlay-шлюзОткрытые интерфейсы Parlay являются объектно ориентированными программами и состоят из

множества классов. Основу архитектуры Parlay составляют три блока (рис. 2): 1)Parlay-остов (Framework), 2)Системные услуги (Services) и 3)Приложения. 

Рис. 2. Схема Parlay-интерфейсов

Эти блоки общаются посредством интерфейсов. На рис. 2 показаны три группы интерфейсов (в соответствии с цифрами на рисунке):

1.      интерфейсы между приложениями и Parlay-остовом. Основные функции этих интерфейсов заключаются в следующем:

аутентификация приложения (в соответствии с предварительно заключенным соглашением о доступе данного пртложения),

авторизация приложения (определяется список требуемых системных услуг),

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

об обслуживании, обеспечение доступа к сетевым функциям (безопасность, контекст, домен и т.д.).2.      интерфейсы между приложениями и Parlay-услугами и выход на сеть связи.3.      интерфейсы между Parlay-остовом и услугами. Основная их задача состоит в регистрации новых системных услуг.

4.2. Пример. Регистрация услуги и ее обнаружениеДля анализа работы Parlay-остова используем пример регистрации услуги и ее обнаружение

(discovery). Этот пример связан с установлением коллективного вызова (MultiParty Call), который подробно описан в стандарте 3GPP[1]. Конечно, приводимые ниже потоковые диаграммы служат лишь иллюстрацией. Для разработки приложений любой программист должен пользоваться оригиналами стандартов, строго придерживаясь к тому же конкретных версий, например, Parlay 3.1, 3.2, 3GPP Release 4 или 5.

На рис. 3 показана последовательность шагов регистрации новой услуги MultiParty Call Control. (Заметим, что наравне с понятием услуга (Service) используется SCF –  Service Capability Feature.) Процесс регистрации и обнаружения услуги (обеспечение доступа к ней в данном сеансе связи) состоит из трех фаз:

1. Регистрация – состоит из трех шагов. Шаг 1 – запрос на аутентификацию услуги, шаг 2 – запрос на регистрацию услуги, шаг 3 – сообщение ссылки на услугу (service factory), после чего Parlay-остов и услуга

знают друг друга.2. Установление соглашения об обслуживании (service agreement). Например, можно оговорить,

что максимальное число участников группового вызова не должно превышать четырех.3. Установление соединения между приложением и услугой. Оно начинается с аутентификации

приложения (шаг 4). Затем следуют: шаг 5 - запрос на доступ к услуге (request Discovery Interface), шаг 6 - обнаружение услуги (discover Service) и шаг 7 - подписание соглашения об обслуживании (sign SLA). Создается менеджер услуги, который будет контролировать использование услуги

данным приложением  (шаги 8 – 10), и начинается использование услуги (шаг 11). 

Рис. 3. Последовательность шагов регистрации услуги и ее обнаружения

Рассмотрим потоковые диаграммы (Sequence Diagrams), раскрывающие суть действий, которые показаны на рис. 3.

Как происходит доступ приложений к услугам

Начальный доступ приложения из безопасной области. На рис. 4 рассматривается приложение, которое находится в том же домене, что и сам Parlay-шлюз, и приложение впервые общается с Parlay-шлюзом. В этом случае не требуется аутентификация клиента, и после передачи метода «initiateAuthentication» интерфейс IрInitial сообщает об успешной аутентификации. После передачи метода «requestAccess» начинается работа приложения.

Рис. 4. Потоковая диаграмма начального доступа приложения из безопасной области

Поясним потоковую диаграмму более подробно:1: Клиент (Client) инициирует процесс аутентификации передачей метода initiateAuthentication

интерфейсу IрInitial. 2: На основе информации о доменных идентификаторах (domainID) остов (Framework) узнает,

что данный клиет находится в безопасной области и дальнейшая аутентификация не требуется. Остов возвращает метод authenticationSucceeded.

3:  Клиент посылает метод requestAccess в интерфейс IрAPILevelAuthentication, сообщая собственный интерфейс доступа. Остов, в свою очередь, возвращает свой интерфейс доступа.

Начальный доступ приложения из небезопасной области. Перед тем как получить доступ к услугам Parlay-шлюза, клиент обязан пройти процесс аутентификации. Получить интерфейс к первичному доступу (Initial Contact) клиент  может, например, через службу URL. Рассмотрим потоковую диаграмму на рис. 5:

1:         Initiate AuthenticationКлиент (Client) инициирует процесс аутентификации передачей метода initiateAuthentication

интерфейсу IрInitial. Клиент сообщает свой интерфейс аутентификации и в ответ получает интерфейс аутентификации остова.

2:         Select Encryption MethodКлиент передает сообщение selectEncryptionMethod в интерфейс IрAPILevelAuthentication, в

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

3:         Authenticate4:         Клиент сообщает, что аутентификация прошла успешно (authentication succeeded).5:         Взаимное завершение аутентификации клиентом и остовом с использованием

интерфейса IрСlientAPILevelAuthentication.6:         Остов подтверждает успешную аутентификацию.7:         Request AccessКлиет посылает метод requestAccess для получения доступа к услугам. Остов в ответ

присылает запрашиваемый интерфейс.

8:         Клиент посылает метод obtainInterface, в котором содержится запрос к раскрытию услуги (service discovery interface). 

Рис. 5. Потоковая диаграмма начального доступа из небезопасной области

Обнаружение и выбор услуги Обнаружение услуги (Service Discovery). На рис. 6 показано, как приложение обнаруживает

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

1. Перед началом процесса раскрытия услуги приложение должно узнать ссылку на интерфейс обнаружения услуги (Service Discovery interface). Для этого приложение посылает метод obtainInterface в интерфейс доступа IpAccess. Сам процесс обнаружения услуги состоит из трех шагов. При повторном обращении к услуге первые два шага можно опустить: можно начать с метода discoverService() без повторного применения методов list/discoverServiceType.

2: Обнаружение услуги (Discovery): первый шаг – запрос списка типов услуги (list service types), которые доступны на сети. В ответ остов посылает out listTypes.

3: Обнаружение услуги: второй шаг – запрос описания тех типов услуги, которыми заинтересовалось приложение. В ответ приходит подробное описание параметров запрошенных типов услуги.

4: Обнаружение услуги: третий шаг – запрос на обнаружение выбранной услуги (discover service).

Рис. 6. Потоковая диаграмма обнаружения услуги

Выбор услуги (Service Selection). После того как клиент получил список версий (типов) запрашиваемой услуги и выбрал одну из версий, требуется оформить разрешение на ее использование (Service Agreement).

Рис. 7. Потоковая диаграмма выбора услуги

Как показано на рис. 7, процесс выбора услуги состоит из двух шагов:1: Послать метод selectService. Метод посылает идентификационный номер услуги serviceID и

получает serviceToken, т.е. текст с соглашением об услуге, включая ее параметры качества обслуживания (service level agreement).

2: Подписать соглашением об услуге (signServiceAgreement). Происходит обмен между менеджерами клиента и остова, т.е. между IpAppServiceAgreementManagement и IpServiceAgreementManagement соответственно.

Сети 3G: от роуминга вызова к роумингу приложений Как повторить успех японской компании NTT DoCoMo, которая имеет 70 тыс. приложений

(сайтов)? Об этом мечтают менеджеры любого оператора связи. К сожалению, успехи DoCoMo вряд ли кому-либо удастся повторить в буквальном смысле, но за рынок услуг следует бороться.

И в настоящей лекции речь пойдет о новых услугах в сетях 3G, о внедрении открытых интерфейсов программирования.

Какие новые услуги предлагает МСЭНа пленарном заседании МСЭ-Т в феврале 2004 г., подводя итоги исследовательскому периоду

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

услуга "Локация" (Location —определение местоположения). Выделены четыре подкласса:- коммерческая услуга "Локация", например справки о ресторанах;- экстренные вызовы (например о помощи);- отслеживание спецслужбами (СОРМ);- для нужд технической эксплуатации сети; услуга "Присутствие" (Presence) (эта услуга регулирует доступ между сетью и абонентом,

участие в чатах, получение электронной почты, голосовой почты и др.), услуги сообщений (Messaging services) например, "Срочные вести" (Instant Messaging), что

обычно увязывается с услугой "Присутствие"; "Push Services" ("услуги проталкивания") (прототипом этих услуг является популярная услуга

коротких сообщений SMS, сюда относятся распространение рекламных объявлений, пользование уcлугами WWW и т.п.),

речевые услуги (распознавание и синтез речи, распознавание личности говорящего, работа автоответчика IVR, VoiceXML-браузера и т.п.).

Все эти услуги, особенно с привлечением мультимедийных средств, сегодня увязывают с мобильными сетями третьего поколения UMTS. Однако легко сообразить, что большинство из них можно реализовать уже сегодня в сетях GSM, достаточно воспользоваться услугой передачи данных GPRS и установить Parlay-шлюз.

Из перечисленных выше услуг наиболее востребованной является услуга "Присутствие" (Presence). Она, в частности, составляет основу исключительно прибыльной услуги Instant Messaging, поэтому на ней остановимся отдельно. Рис. 1 иллюстрирует работу сервера Presence: как он позволяет создавать новые услуги. Пользуясь услугами сервера Presence, пользователь управляет информацией о собственном доступе для других пользователей и для приложений как в домене коммутации каналов CS, так и в домене коммутации пакетов PS, и в подсистеме мультимедийных услуг IMS. Как показано на рис. 1, сервер по заказу пользователя контролирует любые услуги, которые касаются данного пользователя: речевые, передачу данных, дополнительные услуги, мультимедиа.

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

По каким стандартам строить NGN Документы 3GPP сегодня оказывают решающее влияние на архитектуру NGN, поэтому

подробнее остановимся на ключевом узле сетей 3-го поколения – на подсистеме мультимедийных IP-услуг IMS (IP Multimedia Subsystem). Напомним, что все перечисленные выше услуги в стандартах UMTS разделены на четыре класса, по требованиям к качеству обслуживания QoS:

—      Речевые (например, обычный разговор, видеофон, игры on-line)—      Интерактивные  (общение с базой данных, Web-браузинг, доступ к верверу)—      Потоковые (потоковое радио, потоковое видео)—      Фоновые (e-mail, SMS, загрузка из базы данных, прием данных измерений и т.п.).Все эти услуги формируются из медиа-компонент, которые предусмотрены в узле IMS:

Аудио Видео Текст Неподвижное изображение Графические изображения (в том числе трехмерные) Данные

 

 

 

 

 

 

 

 

 

 

Рис. 2. Архитектура IMS (IP Multimedia Subsystem)

  Система IMS действует в режиме коммутации пакетов, и основным протоколом сигнализации является SIP. Основу IMS (рис.2) составляют два узла: 

Контроллер услуг, который здесь выступает под названием OSA Service Capability Server (OSA SCS), и

 

Коммутатор (аналог АТС), который выполняет функцию контроля вызова - Serving-Call Session Control Function (S-CSCF)

Кроме того, имеется медиа-шлюз (MRF - Media Resource Function) и аналог HLR (HSS – Home Subscriber System).

 Отметим главные интерфейсы между узлами системы IMS:

ISC (Internal Service Control Interface) – это интерфейс между S-CSCF и сервером OSA SCS. Этот интерфейс основан на протоколе SIP и стандартизован в 3GPP TS 24.229,

 Cx – интерфейс между коммутатором S-CSCF и регистром HSS (см. 3GPP TS 29.228),

        Sh – интерфейс между контроллером OSA SCS and регистром HSS (см. 3GPP TS 29.328),

 Mr - интерфейс между коммутатором S-CSCF и медиа-шлюзом MRF.

С точки зрения новых услуг наиболее важной частью (на рис. 2) является контроллер OSA SCS, который представляет собой платформу с открытыми интерфейсами к серверу приложений (OSA Application Server). Между ними указан интерфейс “OSA – MPCCS API mapping”, что означает – установление соответствия (mapping) между протоколом SIP, с одной стороны, и интерфейсом контроля вызова MPCCS (MultiParty Call Control Service) в открытой платформе OSA/Parlay, с другой.

 Архитектура IMS идеально подходит для нужд NGN, как иллюстрирует рис. 3:

Обеспечивает миграцию от существующих сетей коммутации каналов к сетям коммутации пакетов,

Обеспечивает простое взаимодействие между мобильными  и фиксированными абонентами, Развитие средств доступа xDSL дает предпосылки для подключения любых терминалов к IMS (в

том числе для передачи потоковых данных), а также способствует переходу к новым IP-сетям, Приближает сети 3GPP, так как интерфейсы основаны на протоколе сигнализации SIP и

протоколе тарификации DIAMETER (который приходит на смену протоколу RADIUS), Реализует весь набор новых услуг: традиционный разговор и видеотелефонию, услуги

сообщений (Instant Messaging, MMS), доставку контента (видео-потоки, распределение ТВ-каналов) и т.д.

На рис. 3 показаны четыре области для реализации приложений:

1. Рассмотренная выше IMS-подсистема, которая является базовой (SIP-based Core IMS)2. Обеспечение потоковых услуг (по протоколу RTSP)3. Подсистема традиционной сети ТфОП (по протоколу ISDN) c эмуляцией SIP-протокола4. Прочие мультимедийные подсистемы

  

 Рис. 3. Общий вид сети NGN в переходном состоянии наличия средств доступа xDSL и IP-каналов

 

 Виртуальная домашняя среда

 Это новое понятие часто встречается в документах 3GPP. Виртуальная домашняя среда VHE (Virtual Home Environment) должна обеспечить роуминг приложений. Но в этом случае имеется существенное отличие от роуминга вызова. Как известно, при перемещении пользователя в гостевой сети (visited network) создается гостевой регистр VLR (сокращенная копия домашнего регистра HLR). В части приложений ситуация другая: информация из сервера приложений не перемещается. Для того чтобы воспользоваться приложением, необходимо организовать удобное общение с сервером, который находится в домашней сети (рис. 4,а) или доступен из домашней сети (рис. 4,б). В этом и заключается смысл понятия VHE. Прокси-сервер гостевой сети P-CSCF обращается к обслуживающему серверу домашней сети S-CSCF, который в свою очередь обращается к платформе приложений (в частности, к Parlay-шлюзу).

Рис. 4. Схема виртуальной домашней среды VHE: обслуживающий сервер S-CSCF общается с платформой приложений, которая расположена в домашней сети (случай а) или является внешней

(случай б)

Рассмотрим пример роуминга приложений (рис. 5). Пусть пользователь UEa желает соединиться с пользователем Uеb. Пользователь UEb находится в гостевой сети и имеет соглашение с сервером приложений AS о переадресации входящих вызовов по номеру UЕc, но не от всех пользователей, а только от тех, номера которых включены в список по услуге Presence.

 

 Рис. 5. Переадресация вызова на основе правил маршрутизации, которые размещены во внешнем сервере приложений

 

Как показано на рис. 5, в переадресации вызова участвуют четыре сети, а также два сервера приложений — из домашних сетей пользователей UЕb и UЕc (со своими домашними регистрами HSS), которые подключены к сети через шлюзы OSA. В маршрутизации вызова участвуют три типа устройств:

—     прокси-сервер P-CSCF;

—     обслуживающий сервер S-CSCF;

—     промежуточный сервер I-CSCF.

 На рис. 6 приведена потоковая диаграмма между 12 устройствами, которые приведены на рис. 5. Сообщения между устройствами условно соответствуют сообщениям протокола SIP. Поясним начальную часть диаграммы.

1. Сервер I-CSCF домашней сети пользователя UEb получает сообщение SIP Invite от сервера S-CSCF с параметрами UЕa-вызова.

2. I-CSCF запрашивает в HSS адрес сервера S-CSCF.

3. HSS возвращает адрес S-CSCF.

4. I-CSCF переправляет SIP Invite к S-CSCF.

5. S-CSCF общается с сервером приложений AS (посредством шлюза OSA) и при условии вхождения номера вызывающего пользователя в заданный список получает инструкции о маршрутизации вызова Uec.

6. Уведомление UEa о переадресации вызова.

7. Ответное сообщение Response.

8. Сообщение SIP Invite передается серверу I-CSCF пользователя UEc.

9. Данный сервер I-CSCF запрашивает регистр HSS об адресе обслуживающего сервера S-CSCF.

10. HSS возвращает запрашиваемый адрес.

11. Следующие шесть шагов диаграммы читатель разберет самостоятельно (при необходимости обращаясь к документу 3GPP TR 23.955).

12. Последний шаг диаграммы (за номером 17) заключается в выборе способа передачи и установления соединения между пользователями UEa и UEc (см. 3GPP TS 23.228.).

 

Рис. 6. Потоковая диаграмма услуги "Переадресация вызова" (по заданному списку входящих вызовов)