В двух предыдущих заметках (VoLGA и CSFB) о вариантах предоставления голоса в LTE - я описывал так называемые "костыли".

LTE является all-IP сетью, при этом и VoLGA и CSFB - этот попытка предоставить голосовые сервисы путем возврата к казалось бы более не нужному в all-IP сети CS домену. Зачем это планируется - понятно. Это и переиспользование существующего (уже купленного и, возможно, не так давно) оборудования, и ясные и отработанные годами механизмы интерконнекта и роуминга, возможность безболезненной интеграции различных IN-сервисов, которые есть и работают сейчас, и простота и прозрачность в обеспечении межсистемных хэндоверов (переходов) из LTE в UMTS/GSM и т.д.

При этом, все операторы и производители оборудования понимают, что существует одно единственное решение для долгосрочной перспективы (я не рассматриваю ситуацию, при которой все операторы являются всего-лишь провайдерами доступа в сеть, а все сервисы - сетевые, типа Skype), которое сможет в полной мере раскрыть потенциал новых all-IP сетей и решение это - IMS (IP Multimedia System).

Рассказать, что такое IMS, в рамках одной статьи не представляется возможным, кроме того IMS – очень сложная и многогранная архитектура, поэтому я попробую кратко остановиться на основных элементах сети и выделить основные изменения, которые внесены недавним документом IMS OneVoice Profile.

По традиции – список использованной литературы и ссылки на другие источники.

• IMS OneVoice Profile – собственно, сам документ, о котором пойдет речь
• The IMS, IP Multimedia Concepts and Services – отличная книжка по IMS, написанная инженерами Nokia и Nokia-Siemens
• The IMS Lantern – блог про IMS от французского специалиста, занимающегося консалтингом в области IMS (больше не поддерживается)
• WirelessMoves – блог Мартина Саутера, немецкого телеком-аналитика и консультанта

Картинка LTE/SAE

Картинка IMS

Этап 1 (получение IP адреса)

IMS по своему названию предполагает постоянную доступность терминала по IP (IP connectivity), т.е. терминал должен получить IP-адрес, по которому с ним можно связаться. В IMS процедуры получения терминалом IP-адреса по сути не изменились (по сравнению с GSM/UMTS), хотя ранее не использовавшиеся (но заложенные в стандарте) механизмы будут более востребованы в IMS. В сетях GSM/UMTS коннективность терминала обеспечивается RAN и SGSN/GGSN. Если абонент в домашней сети - все понятно, если же абонент в визитной сети - в этом случае используется SGSN визитной сети и как правило (обратное возможно и называется local breakout, но реальные примеры мне неизвестны) домашний GGSN. Поскольку для любых IP сервисов терминал виден через GGSN - весь трафик к/от терминала идет через домашний GGSN (отсюда такая его стоимость, кстати:)).

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

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

Этап 2 (Регистрация терминала в сети)

IMS является для сети LTE/SAE одним из многих "внешних" сервисов, работающих поверх IP. Фактически это означает, что терминал выполняет раздельную регистрацию в EPC (Evolved Packet Core) и IMS. Процедура регистрации терминала в EPC одинакова для любых сервисов, работающих over LTE (например для IMS и VoLGA), т.е. запрос на регистрацию приходит в MME, MME идет в HSS, получает данные и происходит регистрация терминала в EPC. После регистрации в EPC, терминал (точнее, IMS приложение на терминале) должен выполнить регистрацию в IMS домене, для чего необходимо определить PDN (Packet Data Network), которая используется для сервиса IMS. В терминале явным образом конфигурируется APN (Access Point Name), с помощью которого определяется необходимая PDN. Далее происходит общение терминала с P-CSCF и регистрация терминала в IMS домене. По этим ссылкам можно изучить процедуры регистрации в EPC и в IMS в подробностях.

Пара слов об идентификации пользователя. В IMS вводится новый тип карт - ISIM (IMS Services Identity Module). Точнее, вводится новый тип "приложения", которое хранится на UICC (Universal Integrated Circuit Card), при этом на одной UICC теоретически может одновременно присутствовать несколько "приложений".

На карточке с ISIM содержится следующая информация:

• Private User Identity (аналог IMSI в GSM/UMTS)
• Public User Identity (аналог MSISDN в GSM/UMTS), их у абонента может быть несколько
• Home Network Domain URI - домашний домен пользователя, используется при регистрации карты для определения адреса, на который отправлять запрос о регистрации в сети
• Long Term Secret - используется для аутентификации и вычисления ключей шифрования

Очевидно, что наилучшим вариантом в сети IMS является использование ISIM, однако регистрация в IMS возможна и с использованием USIM (обычные SIM не поддерживаются из-за отсутствия Long Term Secret), т.е. наиболее перспективным вариантом будет как раз использование USIM для регистрации одновременно в LTE и в IMS.

Итак, если пользователь регистрируется в IMS с использованием USIM - его терминал перед регистрацией вычисляет из IMSI следующие данные:

• Temporary Private User Identity. Для IMSI = 250251234567890 значение Temporary Private User Identity будет 250251234567890@ims.mnc25.mcc250.3gppnetwork.org (правила пересчета прозрачны и понятны из приведенного примера, TS 23.003)
• Temporary Public User Identity. Значение совпадает с предыдущим, но начинается с "sip:", т.е. sip:250251234567890@ims.mnc25.mcc250.3gppnetwork.org
• Home Network Domain URI. Аналогично, будет sip:ims.mnc25.mcc250.3gppnetwork.org

Наконец, есть возможность регистрации в IMS терминала без USIM/ISIM карты. В этом случае используется тот же набор параметров, которые хранятся в так называемом IMC (IMS Credential), IMC не используется если в терминале стоит ISIM или USIM.

Этап 3 (исходящий/входящий вызов)

Документ OneVoice Profile (Annex A) описывает наиболее вероятный способ построения сети оператором, когда этот оператор уже имеет развернутую сеть GSM/UMTS. Согласно OneVoice Profile, терминал должен поддерживать процедуру combined EPS/IMSI attach, т.е. уметь одновременно регистрироваться в GSM/UMTS и LTE доменах. В результате успешной регистрации в обоих доменах - исходящий голосовой вызов может быть установлен как через GSM/UMTS сеть (обычный CS звонок), так и через LTE/IMS сеть (IMS звонок).

Решение о выборе домена (Domain Selection) для исходящего вызова принимается исходя из следующих условий (TS 23.221):

• состояние терминала в CS Domain. Состояние может быть - attached или detached
• состояние терминала в IMS Domain. Состояние может быть - registered или unregistered
• домен, использовавшийся для аналогичного сервиса в предыдущий раз
• пользовательские настройки или операторские ограничения (например, в роуминге абоненту может быть доступен только CS сервисы)

Нужно понимать, что (в отличии от описываемого далее Terminating Access Domain Selection) выбор домена делает именно терминал, а не сеть.

При выборе домена для входящего на терминал вызова (Terminating Access Domain Selection) дополнительно принимаются во внимание следующие факторы:

• возможности терминала и сети
• вид и тип используемых в входящем звонке данных. Т.е. если поступает обычный голосовой звонок (пусть даже из соседнего IMS домена) - его можно передать на терминал как в виде IMS звонка так и в виде обычного CS звонка. При этом, видеозвонок высокого разрешения, например, получится приземлить только через IMS, т.к. возможности UMTS видеозвонков (в том числе разрешение) ограничены стандартом, а значит сеть не сможет передать их через UMTS, а терминал не сможет их принять через UMTS.

Поскольку (как уже писал чуть выше) самым распространенным случаем будет наличие у оператора одновременно CS домена и IMS домена, между ними должно быть взаимодействие, по меньшей мере должны осуществляться хэндоверы из одного домена в другой без потери установленных сессий и с возможностью пользования Suplementary Services (дополнительными услугами). OneVoice Profile налагает на сеть оператора требование поддержки TS 23.216 - Single Radio Voice Call Continuity (SRVCC).

 

Single Radio Voice Call Continuity (SRVCC)

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

Основной смысл SRVCC следующий - в CS/IMS сети, поддерживающей VCC, любой вызов (CS originating/terminating и IMS originating/terminating) устанавливается через IMS VCC.

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

• исходящий звонок с терминала, который поддерживает SRVCC и находится в CS домене сети с поддержкой SRVCC

1. Терминал делает исходящий вызов, который через радиосеть GSM/UMTS поступает в MSC.

2. Звонок (несмотря на то, что он CS originating и, возможно, закончится также в CS домене) должен пройти через IMS домен для выполнения процедуры Anchoring (привязывание), которая фиксирует звонок в VCC Application Server и сохраняет эту привязку на протяжении всего звонка. С помощью этой привязки при необходимости можно легко выполнить переход звонка между CS и IMS доменами в любую сторону и любое количество раз. Все абоненты с SRVCC имеют соответствующую CAMEL-подписку, которая обеспечивает отправку Initial DP с запросом инструкций (а также с информацией о вызывающем абоненте - MSISDN, IMSI и т.д.) в адрес gsmSCF.

3. gsmSCF обращается в VCC Application Server.

4. VCC AS выделяет IMRN (IMS Routing Number, аналог MSRN) и организует связку MSISDN-IMRN.

5-6. Выделенный IMRN доставляется в MSC в сообщении Connect.

7. MSC устанавливает соединение, используя IMRN в качестве Called Party Number в сторону IMS домена.

8. MGCF (Media Gateway Control Function) выполняет преобразование сигналлизаций (ISUP или BICC или SIP-I) в понятный для IMS SIP и отправляет SIP-INVITE в сторону I-CSCF.

9. I-CSCF транслирует INVITE в сторону VCC-AS.

10. VCC-AS из INVITE, содержащего IMRN, находит у себя соответствие MSISDN-IMRN и преобразовывает MSISDN в SIP-URI

11. VCC-AS отправляет INVITE с измененным SIP-URI (он теперь содержит не IMRN, а адрес вызывающего абонента) обратно в IMS (конкретно в S-CSCF), указывая в поле CONTACT сообщения INVITE адрес VCC-AS. Указав в поле CONTACT свой адрес, VCC-AS выполняет процедуру Anchoring и привязывает себя к этому звонку на всем его протяжении.

12. S-CSCF продолжает процедуру установления соединения в сторону CS домена или IMS домена, в зависимости от того, где находится вызываемый абонент и как прошла процедура Terminating Domain Selection.

• входящий звонок на терминал, который поддерживает SRVCC

1. На терминирующий S-CSCF поступает INVITE с адресом вызываемого абонента.

2-3. Поскольку вызываемый абонент в данном случае является VCC-абонентом, по какому-то фильтру определяется необходимость включить в дальнейшую обработку VCC AS.

4. Anchoring

5. Terminating Domain Selection. Как было отмечено выше, выполняется сетью (а не терминалом, как originating), критерии также указаны выше.

6a-7a. В случае выбора IMS домена в качестве терминирующего, вызов доставляется до P-CSCF и далее до абонента.

6b. В случае выбора CS домена в качестве терминирующего, определяется номер CSRN (CS routing number, близок по смыслу к MSRN).

7b-8b. Вызов доставляется до MSC/VLR, на котором находится в данный момент вызываемый абонент

Domain Transfer Procedure

Выше рассмотрены примеры вызовов, выполнявшихся с использованием SRVCC. Далее рассмотрим непосредственно процедуру смены домена в течении разговора, т.е. то, ради чего и придуман VCC.

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

• VDI (VCC Domain Transfer URI). Это URI, который использует терминал при смене домена из CS в IMS (очень отдаленно напоминает по смыслу хэндоверный номер в GSM/UMTS).
• VDN (VCC Domain Transfer Number). Телефонный номер, смысл такой же как у VDI, только используется при смене домена с IMS на CS.
• Preferred Domain. Операторское предпочтение по использованию CS или IMS домена.
• параметры, определяющие политику оператора в плане разрешения терминалу инициировать процедуры смены домена

Картинка выше демонстрирует процедуру Domain Transfer из IMS в CS, инициированную терминалом. Похожий пример разобран выше, поэтому подробно останавливаться не буду.

Roaming

Основные аспекты, касающиеся роуминга, были описаны в разделе про получение терминалом IP адреса. Хочется повторить – при наличии в домашней сети IMS домена, абонент может получить IMS услуги в любой визитной сети, с которой у домашнего оператора есть GPRS-роуминг.

При этом, совершенно очевидно, что в полной мере преимущества IMS в роуминге абонент сможет оценить в случае наличия в визитной сети именно IMS роуминга, т.е. работа с домашней сетью через P-CSCF визитной сети. В этом случае вместе с оптимальностью путей передачи сигнального трафика (Control Plane) и абонентского трафика (User Plane), абонент получит поддержку в полной мере IMS сервисов (в том числе VoIP, который очевидно будет ограничен в предыдущем случае возможностями GSM/UMTS RAN и высокой стоимостью GPRS-роуминга).

SMS

Сервис SMS должен быть организован в виде SMS_over_IP, как описано в TS 24.341. Для поддержки сервиса в IMS домене используется Application Server – IP-SM-GW. В качестве протокола используется SIP (метод MESSAGE), предусматривается возможность работы через GPRS/UMTS RAN. Картинка ниже демонстрирует в общих чертах механизм отправки сообщения:

Дополнительные услуги

OneVoice Profile определяет (т.е. делает обязательными к применению) самые основные дополнительные услуги:

• Calling Line Identification Presentation/Restriction (по нашему – АОН/Анти-АОН)
• Call Diversion (переадресация)
• Call Barring (запрет вызовов)
• Call Waiting/Call Hold (ожидание вызова)
• Multi-Party Conference (конференц-связь)

Здесь следует оговориться, что механизм SRVCC не поддерживает самостоятельно трансфер между доменами multiparty вызова (..т.е. установленного конференц-звонка). Для поддержки данного режима необходимо наличие на сети IMS Centralized Services (ICS). OneVoice Profile содержит ссылку на спецификацию ICS (TS 23.292), однако никак не регламентирует его использование.

Выводы

IMS OneVoice выгоден операторам, у которых сейчас сети не 3GPP стандартов. Как пример – Verizon Wireless. Для них это чуть ли не единственный способ получить голос в сети LTE (CSFB для них очевидно мимо, VoLGA – требует установки оборудования, значит немногим лучше).

IMS OneVoice выгоден операторам, у которых есть построенные GSM/UMTS сети, поскольку позволяет предложить существующим абонентам новые услуги и обеспечить непрерывность основных сервисов.

IMS OneVoice выгоден производителям оборудования, причем не только из ведущей 5-ки (оборудование IMS вполне способны выпускать и уже выпускают датаком-вендоры). Вендоры продают новые маршрутизаторы, коммутаторы, сервера, IMS возможно использовать на сети с любым типом доступа и это открывает новые горизонты для производителей.

IMS OneVoice, возможно, невыгоден разработчикам сетевых сервисов и приложений, поскольку требует от них поддержки громоздкой и возможно неоптимальной для этих задач архитектуры (вообще одним из неверующих в IMS является один из известных сетевых аналитиков, Dean Bubley).

Время покажет:)

© lazymoose, впервые опубликовано в ЖЖ, MForum.ru

Предыдущие части:

• Голос в LTE. VoLGA >>
• Голос в LTE. CS Fallback >>
• Также по теме LTE есть подборка "ликбезовского" уровня здесь >>