Особенности реализации конвергентных услуг на базе платформы IMS

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

 

Рассматривая платформу IMS в качестве технологии для реализации конвергентных услуг, ее нельзя ставить в один ряд с другими вариантами организации услуг FMC, поскольку функции данной технологии намного шире. Основное отличие IMS заключается в том, что она является технологией уровней управления и услуг, в то время как другие способы реализации услуг FMC представляют собой технологии доступа. В частности, вполне возможно использовать комбинацию рассмотренной выше технологии UMA на уровне доступа и подсистемы IMS как средства предоставления современных мультимедийных услуг. Однако ниже в данном разделе будет рассматриваться случай реализации конвергентных услуг полностью на базе технологии IMS.

Сегодня уже целый ряд производителей имеет готовые решения для реализации конвергентных услуг на базе IMS. Так, компания Siemens предлагает законченное конвергентное решение для фиксированных и мобильных сетей связи в двух версиях: FMC 1.x и 2.x. Компания Motorola создала решение на базе радиочастотной идентификации (RFID), собственную платформу IMS и другие важные компоненты. Предложила свою продукцию фирма Ericsson и другие вендоры.

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

 

 

 

Таблица 1 Комплексные решения для организации конвергентных сетей

 

Архитектура конвергентной сети на базе IMS

 

 

 

Рис 1.5. Архитектура реализации конвергентных услуг на базе платформы IMS

 

 

Пример реализации конвергентных услуг на базе платформы IMS представлен на рис. 1.5. Как видно из рисунка, платформа технологии IMS позволяет создать архитектуру независимого доступа на основе IP-протокола, благодаря чему обеспечивается взаимодействие голоса и данных как для фиксированных сетей (PSTN, ISDN, Интернет), так и для мобильных пользователей (GSM, CDMA). Технология IMS может использоваться в сетях 2-го и 3-го поколений сетей подвижной связи стандартов GSM и cdma2000 и осуществлять взаимодействие с любыми IP-сетями (например, GPRS, WLAN, xDSL).

Технология IMS (IP Multimedia Subsystem) представляет собой набор функциональных сетевых элементов, необходимых для предоставления мультимедийных услуг пользователям терминалов сетей следующего поколения (NGN). Перечислим базовые функциональные элементы IMS-платформы:

·CSCF (Call Session Control Function) - функция управления состоянием вызова - SIP-сервер;

·MGCF (Media Gateway Control Function) - объект, осуществляющий управление шлюзом IM-MGW;

·MGW (Media Gateway Function) - мультимедийный шлюз;

·MRFC (Multimedia Resource Function Controller) - контроллер управления функциями мультимедийных ресурсов;

·MRFP (Multimedia Resource Function Processor) - процессор обработки функций мультимедийных ресурсов;

·HSS (Home Subscriber Server) - опорная база данных оператора сети, которая содержит информацию, относящуюся к подписке пользователя;

·SBG (Session Border Gateway) - пограничный шлюз сессий. Это оборудование, реализующее VoIP и мультимедийный шлюз IP. Шлюз SBG разделен на пограничный шлюз доступа Access SBG (A-SBG) и на пограничный сетевой шлюз Network SBG (N-SBG);

·AS (Application Server) - серверы приложений;

·Network&Service Management - блок управления сетью и услугами, отвечающий за выделение IP-адресов, начисление оплаты и т.п.

При этом технология IMS не определяет никаких новых протоколов взаимодействия, а функционирует с использованием существующих протоколов сети Интернет, определенных IETF (SIP, SDP и Diameter). Подсистема IMS использует протокол SIP (Session Initiation Protocol) в качестве базового.

 

 

Модель реализации конвергентных услуг с использованием технологии IMS получила название Voice Call Continuity (VCC). Стандартизацией VCC занимается партнерство 3GPP. Ожидается, что окончательная версия данной спецификации появится в 2006 г.

Модель VCC обеспечивает прозрачное прохождение речевого вызова при переходах пользовательского терминала между сетью СПС, построенной на базе любой технологии (GSM, UMTS, CDMA), и любыми сетями беспроводного доступа, поддерживающими передачу речи поверх IP (VoIP). Технология IMS/VCC дает возможность использовать единый телефонный номер, а также обеспечивать хэндовер между сетью сотовой подвижной связи и WLAN. Как и в случае с UMA, абонент конвергентных услуг на базе технологии IMS/VCC должен использовать двух-режимный пользовательский терминал, способный функционировать и в сети сотовой связи, и в сети широкополосного беспроводного доступа (например, Wi-Fi). Когда терминал работает в сети WLAN, для передачи голосовой информации между терминалом и элементами управления вызова в опорной сети IMS используется сигнализация SIP, и пользовательский трафик передается по протоколу RTP.

Основные ограничения реализации конвергентных услуг

Технология UMA

Как было показано выше, для реализации решения FMC на базе технологии UMA необходимо внести небольшие изменения в существующую инфраструктуру сети GSM/GPRS: установить новые контроллеры UNC, обеспечивающие взаимодействие с пользовательскими терминалами, когда они находятся в сети ра-диодоступа WLAN, а также модернизировать программное обеспечение в части биллинга и аутентификации абонентов.

 

 

Однако, несмотря на относительную дешевизну решения UMA, связанную с незначительным изменением существующей инфраструктуры сети, может возникнуть ряд скрытых статей расходов на модернизацию сети. Дополнительные затраты возникают, в основном, в связи с резким увеличением объемов трафика, приходящегося на существующие элементы сети, поскольку контроллеры UMA подключаются к опорной сети GSM/GPRS по традиционным интерфейсам A и Gb. В результате может возникнуть необходимость расширения таких узлов, как MSC, SGSN и GGSN, а возможно, даже их замены.

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

Кроме того, технология UM A может оказаться неприменимой для корпоративных сетей WLAN в связи с тем, что в подобных сетях обычно используются шлюзы/межсетевые экраны и средства AAA (Authentication, Authorization and Accounting) для доступа к услугам.

 

С точки зрения предоставления перспективных мультимедийных услуг подсистемы IMS технология UMA также имеет свои слабые стороны, поскольку не обеспечивает прямой интеграции пользовательского оборудования с протоколом SIP. Сеть UMA представляет собой туннель (мост) между мобильной станцией и контроллером UNC, из чего следует, что терминал пользователя не является объектом в сети IP "от начала до конца". Последним элементом, который будет "виден" со стороны IP-сети, является контроллер сети UMA. В результате невозможно обеспечить прозрачную работу некоторых услуг, требующих непосредственной адресации пользовательского оборудования по протоколу SIP, например услуги Presence.

 

 

Технология IMS/VCC

 

 

Технология IMS/VCC не имеет основных недостатков, свойственных технологии UMA. Во многом это связано с тем, что, как уже говорилось, IMS и UMA являются технологиями разного уровня. UMA - это технология доступа, а IMS - технология уровня управления/услуг.

Также вполне естественной для решения IMS/VCC выглядит полная интеграция пользовательского оборудования с протоколом SIP, что обеспечивает предоставление абоненту всего спектра современных мультимедийных услуг IMS.

Внедрив у себя на сети решение IMS/VCC, оператор может разгрузить существующую сеть СПС, уведя трафик в среду Wi-Fi и, возможно, в проводные широкополосные сети передачи данных.

Несмотря на ряд положительных сторон решения IMS/VCC, на сегодняшний день у него существует ряд ограничений.

Основным недостатком решения организации услуг FMC на базе IMS/VCC является незаконченность процесса стандартизации. На текущий момент 3GPP пока не утвердил техническую спецификацию, регламентирующую процедуру хэндовера между доменом с коммутацией каналов и доменом IMS.

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

Вследствие незавершенности процесса стандартизации появление на рынке терминалов с поддержкой IMS/VCC ожидается только в начале следующего года. Это объясняется также более ранним появлением технологии UMA на рынке услуг FMC и соответственно отсутствием необходимой мотивации у производителей двухрежимных терминалов в части выпуска мобильных станций с поддержкой IMS/VCC. С точки зрения производителей оборудования, существует определенный риск, связанный с выпуском терминалов, поддерживающих новую технологию, ведь она может не найти отклика со стороны операторов связи (с учетом того, что уже существует альтернативная ей действующая технология UMA).

Технология IMS основана на протоколе SIP, что может вызывать определенные проблемы при использовании частных IP-адресов, которые обычно распространены в домашних и корпоративных сетях, подключенных через шлюз или межсетевой экран. С точки зрения оператора, проблемы будут заключаться в том, что реализация некоторых услуг будет зависеть от этих шлюзов/межсетевых экранов, не находящихся под контролем оператора (технология UMA использует туннель IPsec, который имеет меньше проблем при преодолении NAT). Однако в последнее время функции NAT становятся все более стандартизованными, что должно снизить значимость описанной проблемы.

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

 

Выводы:

 

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

 

·требуемая скорость внедрения услуг FMC;

 

·существующая сетевая инфраструктура;

 

·планы в отношении дальнейшей эволюции сети связи.

 

Технологию UMA можно рекомендовать к использованию при решении краткосрочных задач операторами сетей СПС, связанных с расширением зоны покрытия своих сетей в отдельных зданиях, а также с обеспечением контроля за трафиком беспроводных сетей доступа, при условии наличия достаточно разветвленной инфраструктуры сетей Wi-Fi. Кроме того, применение готовых решений UMA обеспечит максимально быстрые сроки внедрения услуг FMC в существующих сетях GSM/GPRS.

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

Еще одним вариантом использования технологий UMA и IMS является их комбинация. Особенно это удобно в случае использования оборудования одного производителя, так как обеспечит его полную совместимость.

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

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

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

 

 

Архитектура IMS

 

 

Для IMS разработана многоуровневая архитектура с разделением транспорта переноса трафика и сигнальной сети IMS для управления сеансами (рис. 2.1). Таким образом, при разработке IMS на мобильные сети фактически перенесена основная идеология Softswitch. В IMS выделяются:

 

· пользовательский уровень или уровень передачи данных (User Plane)

 

 

· уровень управления (Control Plane)

 

 

· уровень приложений (Application Plane).

 

 

В этих плоскостях 3GPP специфицирует не узлы сети, а функции. Это означает, что IMS-архитектура, как и архитектура Softswitch, также преставляет собой набор функций, соединенных стандартными интерфейсами.

При этом в случае IMS функции тоже оказываются описанными в стандартах. Разработчики вправе скомбинировать несколько функций в од- ном физическом объекте или, наоборот, реализовать одну функцию распределенным образом.

 

 

Рис. 2.1. Архитектура IMS

 

К функциональным возможностям IMS можно отнести:

· Мультимедийные IP-сеансы

· Качество обслуживания

· Взаимодействие с другими сетями

· Инвариантность доступа

· Создание услуг и управление услугами

 

1. Мультимедийные IP-сеансы

IMS представляет широкий спектр мультимедийных услуг, но основная услуга IMS – двусторонняя аудио/видео связь. Для этого архитектура IMS должна поддерживать сеансы мультимедийной связи в IP-сетях, должна обеспечивать доступ к услуге пользователям, находящимся как в домашней, так и в визитной. Также пользователи IMS должны иметь возможность комбинировать различные IMS сервисы во время одного мультимедийного сеанса.

 

2. Качество обслуживания

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

 

3. Взаимодействие с другими сетями

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

 

4. Инвариантность доступа

Инвариантность доступа к IMS, получившая название IP connectivity access, предполагает применение любой технологии доступа, которая может обеспечить транспортировку IP-трафика между пользовательским оборудованием и объектами IMS. Таким образом, функциональные возможности IMS инвариантны относительно разных технологий доступа.

 

5. Создание услуг и управление услугами

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

 

 

Рассмотрим функциональные элементы на рис. 2.1 более подробно.

 

 

1. Пользовательские базы HSS и SLF

 

Каждая IMS-сеть содержит один или более серверов пользовательских баз данных HSS. Сервер HSS представляет собой централизованное хранилище информации об абонентах и услугах и является эволюционным развитием HLR (Home Location Register) из архитектуры сетей GSM. Сеть может содержать более одного HSS в том случае, если количество абонентов слишком велико, чтобы поддерживаться одним HSS. Такая сеть, наряду с несколькими HSS, должна будет иметь в своем составе функцию SLF (Subscriber Location Function), представляющую собой простую базу данных, которая хранит соответствие информации HSS адресам пользователей. Узел, передавший к SLF запрос с адресом пользователя, получает от нее сведения о том HSS, который содержит информацию об этом пользователе.

 

 

Рис. 2.2. Логические функции HSS

 

Функция SIP-сервера

 

 

Функция управления сеансами CSCF (Call Session Control Function) является центральной частью системы IMS, представляет собой, по сути, SIP-сервер и обрабатывает SIP-сигнализацию в IMS. Существуют функции CSCF трех типов: Proxy-CSCF (P-CSCF), Interrogating-CSCF (I-CSCF) и Serving-CSCF (S-CSCF).

 

Первая из перечисленных, функция P-CSCF – это первая точка взамодействия (на сигнальном уровне) пользовательского IMS-терминала и IMS-сети. С точки зрения SIP, она является входящим/исходящим прокси-

23сервером, через который проходят все запросы, исходящие от IMS- терминала или направляемые к нему. Однако функция P-CSCF может вести себя и как агент пользователя UA, что необходимо для прерывания сеансов в нестандартных ситуациях и для создания независимых SIP-транзакций, связанных с процессом регистрации.

I-CSCF – еще один SIP-прокси, расположенный на границе административного домена Оператора. Когда SIP-сервер определяет следующую пересылку для некоторого SIP-сообщения, он получает от службы DNS адрес I-CSCF соответствующего домена. Кроме исполнения функций SIP-прокси I-CSCF взаимодействует по протоколу Diameter с HSS и SLF, получает от них информацию о местонахождении пользователя и об обслуживающей его S-CSCF. Если никакая функция S-CSCF еще не назначена, функция I-CSCF производит ее назначение.

 

S-CSCF – центральная интеллектуальная функция на сигнальном уровне, т.е. функция SIP-сервера, который управляет сеансом. Помимо этого, S-CSCF выполняет функцию регистрирующего сервера сети SIP (SIP-registrar), то есть поддерживает привязку местоположения пользователя (например, IP-адресом терминала, с которого пользователь получил доступ в сеть) к его SIP-адресу (PUI-Public User Identity).

 

Функция S-CSCF взаимодействует по протоколу Diameter с HSS, получает от последнего данные аутентификации пользователя, пытающегося получить доступ к сети, и данные о профиле пользователя, т. е. перечень доступных ему услуг – набор триггерных точек для маршрутизации сообщения SIP к серверам приложений. В свою очередь, функция S-CSCF информирует HSS о том, что этот пользователь прикреплен к нему на срок своей регистрации, и о срабатывании таймера регистрации.

 

1. Функция PDF

 

Функция Policy Decision Function (PDF) иногда интегрируется с функцией P-CSCF, но может быть реализована отдельно. Эта функция отвечает за выработку политики на основании информации о характере сеанса и о передаваемом трафике (транспортные адреса, ширина полосы и т.д.), полученной от P-CSCF. На базе этой информации PDF принимает решение об авторизации запросов от GGSN и производит повторную авторизацию при изменении параметров сеанса, а также может запретить передачу определенного трафика или организацию сеансов некоторых типов.

 

1. Серверы приложений

 

Серверы приложений (Application Servers), по существу, не являются элементами IMS, а работают, условно говоря, поверх нее, предоставляя ус луги в сетях, построенных согласно IMS-архитектуре. Серверы приложе ний взаимодействуют с функцией S-CSCF по протоколу SIP. Основными функциями серверов приложений являются обслуживание и модификация 24 SIP-сеанса, создание SIP-запросов, передача данных тарификации в центры начисления платы за услуги связи.

Рис. 2.3 Серверы приложений

 

Рассмотрим эти три типа серверов приложений:

 

 

1. SIP AS (SIP Application Server) - классический сервер приложений, предоставляющий мультимедийные услуги на базе протокола SIP;

 

2. OSAnSCS (Open Service Access - Service Capability Server) предоставляет интерфейс к серверу приложений OSA и функционирует как сервер приложений со стороны SnCSCF и как интерфейс между сервером приложений OSA и OSA API - с другой стороны;

 

3. IMnSSF (IP Multimedia Service Switching Function) позволяет использовать в IMS услуги CAMEL (Customized Applications for Mobile Network Enhanced Logic), разработанные для GSM сетей, а также позволяет управляющей функции gsmSCF(GSM Service Control Function) управлять IMS-сеансом. Со стороны SnCSCF сервер IMnSSF функционирует как сервер приложений, а с другой стороны - как функция SSF(Service Switching Function), взаимодействующая с gsmSCF по протоколу CAP

 

 

Помимо обязательного для серверов приложений всех типов SIP-интерфейса со стороны IMS, они могут также иметь интерфейсы к HSS, причем SIP AS и OSAnSCS взаимодействуют с HSS по протоколу Diameter для получения данных о пользователе или для обновления этих данных в HSS, а информационный обмен между IM SSF и HSS ведется по протоколу MAP

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

 

 

1. Функция MRF

 

Теперь рассмотрим MRF (Media Resource Function), являющуюся источником медиаинформации в домашней сети и позволяющую воспроизводить разные объявления, смешивать медиапотоки, транскодировать битовые потоки кодеков, получать статистические данные и анализировать медиаинформацию. Функция MRF делится на две части:

· MRFC – Media Re- source Function Controller

 

· MRFP – Media Resource Function Processor.

 

MRFC находится на сигнальном уровне и взаимодействует с S-CSCF по протоколу SIP. Используя полученные инструкции, MRFC управляет по протоколу Megaco/H.248 процессором MRFP, находящимся на уровне передачи данных, а тот выполняет все манипуляции с медиаинформацией.

 

6. Функция BGCF

 

 

Breakout Gateway Control Function – это SIP-сервер, способный вы полнять маршрутизацию вызовов на основе телефонных номеров. BGCF используется только в тех случаях, когда сеанс инициируется IMS- терминалом, а адресатом является абонент сети с коммутацией каналов (например, ТфОП или мобильной сети 2G). Основными задачами BGCF яв ляется выбор той IMS-сети, в которой должно происходить взаимодействие с сетью коммутации каналов, или выбор подходящего ТфОП/CS шлюза, если это взаимодействие должно происходить в сети, где находится сам сервер BGCF. В первом случае BGCF переводит сеанс к BGCF выбранной сети, а во втором – к выбранному ТфОП/CS шлюзу.

 

 

Шлюз ТфОП/CS

 

 

Шлюз ТфОП/CS поддерживает взаимодействие IMS-сети с ТфОП и позволяет устанавливать соединения между пользователями этих сетей. Он имеет распределенную структуру, характерную для архитектуры Softswitch:

 

· SGW – Signaling Gateway

 

· MGCF – Media Gateway Control Function

 

· MGW – Media Gateway.

 

 

 

8. Шлюз безопасности SEG

 

Для того чтобы защитить уровень управления в домене безопасности (security domain), представляющем собой такую область сети, которая принадлежит одному провайдеру услуг, в которой действуют единые административные правила и сетевая политика, трафик на входе в этот домен и на выходе из него будет проходить через шлюз безопасности SEG (Security Gateway). Как правило, границы домена безопасности совпадают с границами сети провайдера, а шлюзов SEG в сети провайдера обычно присутствует несколько. В качестве SEG часто выступают пограничные контроллеры SBC.

 

 

Основные протоколы IMS

Архитектура IMS представляет собой набор функциональных объектов, соединенных стандартными интерфейсами. Взаимодействие функциональных объектов IMS осуществляется с использованием протоколов сети Интернет.

Протоколы подсистемы IMS обеспечивают управление мультимедийными сессиями (SIP, SDP), передачу пользовательского трафика (RTP и RTCP), регистрацию, аутентификацию, авторизацию, поддержку мобильности пользователя (Diameter).

Протокол H.248 используется для управления пользовательским трафиком при оказании услуг и взаимодействии сетей.

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

 

Табл. 2

Cx	Взаимодействие между CSCF и HSS
Gm	Обмен сообщениями между оборудованием пользователя и функциями CSCF
ISC	Обмен сообщениями между функциями CSCF и серверами приложений AS
Ix	Взаимодействие между элементами IBCF и TrGW
Izi	Взаимодействие между TrGW и пограничными шлюзами различных мультимедийных сетей
Mi	Обмен сообщениями между S-CSCF и BGCF
Mj	Обмен сообщениями между BGCF и MGCF в одной IMS сети
Mn	MGCF управляет оборудования медиа шлюза IMS-MGW
Mw	Обмен сообщениями между функциями CSCF
Mx	Обмен сообщениями между I-CSCF/BGCF и IBCF

 

 

Протокол SIP

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

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

Разработкой протокола начала заниматься организация IETF в 1996 году. В ноябре 2000 года SIP был утверждён как сигнальный протокол проекта 3GPP и основной протокол архитектуры IMS. Наряду c другим распространённым протоколом H.323, SIP — один из протоколов, лежащих в основе Voice over IP.

В основу протокола легли следующие принципы:

· Простота: включает в себя только шесть методов (функций)

· Независимость от транспортного уровня, может использовать UDP, TCP и т. д.

· Персональная мобильность пользователей. Пользователи могут перемещаться в пределах сети без ограничений. Это достигается путем присвоения пользователю уникального идентификатора. При этом набор предоставляемых услуг остается неизменным. О своих перемещениях пользователь сообщает с помощью сообщения REGISTER.

· Масштабируемость сети. Структура сети на базе протокола SIP позволяет легко ее расширять и увеличивать число элементов.

· Расширяемость протокола. Протокол характеризуется возможностью дополнять его новыми функциями при появлении новых услуг.

· Интеграция в стек существующих протоколов Интернет. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом IETF. Кроме SIP, эта архитектура включает в себя протоколы RSVP (протокол), RTP, RTSP, SDP.

· Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с другими протоколами IP-телефонии, протоколами ТфОП, и для связи с интеллектуальными сетями.

 

Запросы

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

· INVITE — Приглашает пользователя к сеансу связи. Обычно содержит SDP-описание сеанса.

· АСК — Подтверждает приём ответа на запрос INVITE.

· BYE — Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.

· CANCEL — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.

· REGISTER — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.

· OPTIONS — Запрашивает информацию о функциональных возможностях сервера.

Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:

· PRACK — временное подтверждение

· SUBSCRIBE — подписка на получение уведомлений о событии

· NOTIFY — уведомление подписчика о событии

· PUBLISH — публикация события на сервере

· INFO — передача информации, которая не изменяет состояние сессии

· REFER — запрос получателя о передаче запроса SIP

· MESSAGE — передача мгновенных сообщений средствами SIP

· UPDATE — модификация состояния сессии без изменения состояния диалога

 

Ответы на запросы

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

· 1ХХ — Информационные ответы. Показывают, что запрос находится в стадии обработки. Наиболее распространённые ответы данного типа — 100 Trying, 180 Ringing, 183 Session Progress.

· 2ХХ — Финальные ответы, означающие, что запрос был успешно обработан. В настоящее время в данном типе определены только два ответа — 200 OK и 202 Accepted.

· 3ХХ — Финальные ответы, информирующие оборудование вызывающего пользователя о новом местоположении вызываемого пользователя, например, ответ 302 Moved Temporary.

· 4ХХ — Финальные ответы, информирующие об ошибке при обработке или выполнении запроса, например, 403 Forbidden или классический для протокола HTTP ответ 404 Not Found.

· 5ХХ — Финальные ответы, информирующие о том, что запрос не может быть обработан из-за отказа сервера, 500 Server Internal Error.

· 6ХХ — Финальные ответы, информирующие о том, что соединение с вызываемым пользователем установить невозможно, например, ответ 603 Decline означает, что вызываемый пользователь отклонил входящий вызов.

 

 

Протокол SDP

SDP (Session Description Protocol) — сетевой протокол, предназначенный для описания сессии передачи потоковых данных, включая телефонию (ТФОП и VoIP), Интернет-радио, приложения мультимедиа. Кроме этого, пользователи должны согласовать тип и правила кодирования информации, которой они собираются обмениваться, то есть совместно использовать описание сеанса между ними. Такое описание сеанса составляется в соответствии с уже упомянутым протоколом SDP (Session Description Protocol).

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

 

Протокол H.248/Megaco

Протокол управления транспортным шлюзом H.248/Megaco является развитием протокола MGCP. Так же, как и протокол MGCP, он является внутренним протоколом, который работает между функциональными блоками распределенного шлюза – MGCF и MGW, IBCF и TrGW. Принцип действия этого протокола тот же – ведущий/ведомый. Устройства управления MGCF и IBCF являются ведущими, а медиа и транспортный шлюз MGW и TrGW – ведомыми, то есть, шлюзы выполняют команды, которые поступают к ним от устройств управления. Для переноса сигнальных сообщений H.248/Megaco могут использоваться следующие транспортные протоколы: UDP, TCP, а также SCTP. Сообщения протокола H.248/Megaco могут кодироваться двумя способами. Комитетом IETF предложен текстовый способ кодирования сигнальной информации, причем для описания сеансов связи используется протокол SDP. С другой стороны, ITU-T предусматривает двоичный способ представления сигнальной информации по спецификациям абстрактного синтаксиса ASN.1. Устройство управления должно поддерживать оба способа кодирования, а шлюзы – только один из них.

 

Протокол RTP/RTCP

Протокол RTP (Real-time Transport Protocol) работает на транспортном уровне и используется при передаче трафика реального времени. Протокол был разработан в IETF и впервые опубликован в 1996 году.

Протокол RTP переносит в своём заголовке данные, необходимые для восстановления голоса или видеоизображения в приёмном узле, а также данные о типе кодирования информации (JPEG, MPEG и т. п.). В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты.

Спецификация RTP описывает два под-протокола:

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

· Протокол контроля, RTCP, используемый для определения качества обслуживания (QOS), обратной связи и синхронизации между медиа-потоками. Занимаемая полоса пропускания RTCP — мала в сравнении с RTP, обычно около 5 %.

· Управляющий сигнальный протокол, такой как SIP, MGCP или H.248. Сигнальные протоколы управляют открытием, модификацией и закрытием RTP-сессий между устройствами и приложениями реального времени.

· Управляющий протокол описания медиа, такой как Session Description Protocol (SDP).

Протокол DIAMETER