lte eps attach что это значит
Структура сети LTE
P-GW (PDN Gateway)
Функции данного устройства заключаются в выделении IP адреса для UE, соблюдении параметров QoS и осуществлении списаний по счету на основе набора правил, полученных из PCRF (Policy Control and Charging Rules Function). Также P-GW осуществляет фильтрацию поступающих IP пакетов в различные клиентские потоки с конкретным набором параметров QoS при этом используются TFT (Traffic Flow Templates).
На рисунке ниже приводится стек протоколов, используемый в пользовательской плоскости. 
IP пакеты, адресованные UE, туннелируются (GTP-U/UDP/IP) на участке между P-GW и eNodeB (интерфейсы S1 и S5/S8) для последующей их передачи на UE. Стек протоколов на участке между UE и eNodeB состоит из: PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control) и MAC (Medium Access Control) подуровней.
На рисунке ниже приводится стек протоколов, используемый в контрольной плоскости. 
Протоколы, которые используются между UE и eNodeB носят название Access Stratum (AS) протоколы. В контрольной плоскости все протоколы ниже RRC выполняют те же самые функции, что и в пользовательской плоскости. За исключением того, что в контрольной плоскости нет сжатия заголовков.
Протокол RRC (см. описание протокола тут) выполняет главные контролирующие функци, к которым относятся создание потоков, используемых при радио передаче, и конфигурация всех нижележащих уровней.
Взаимодействие между соседними eNodeB осуществляется через интерфейс X2. Описание которого будет добавлено чуть позже.
Технология LTE что это — в чем отличие от 3G и 4G сетей
Разберёмся что такое LTE в смартфоне, и чем оно отличается от привычного 3G. Какие технологии передачи данных предлагают сети четвёртого поколения, и что это даст пользователям?
Что такое LTE
Многие смартфоны поддерживают LTE, но пока не всем пользователям известно, что это значит.
Стандарт является промежуточным этапом в переходе от 3G к 4G. Подключение к такой сети значительно увеличивает скорость передачи данных как загрузки, так и выгрузки. Но несмотря на это, он не дотягивает до технических характеристик, принятых для очередного четвёртого поколения связи.
Технология передачи данных
Сеть нового поколения предоставляет возможность соединения на скорости до 100 Мбит/сек (теоретически максимальная скорость). В реальности она на порядок ниже, все равно технология значительно опережает предыдущий стандарт. В основе лежит пакетная передача данных MIMO, и система кодирования OFDM. Благодаря распределению передающих антенн корреляционная зависимость полностью исключена. В разных странах связь работает на различных диапазонах. Даже разные операторы связи внутри страны нередко используют различные частотные диапазоны.
Сравнение с 3G
Если сравнить два последних поколения сети, действующее и только развивающееся, то получатся следующие выводы:
Все это несомненные превосходства новой сети. Но есть и недостатки, 3G за время своего существования может похвастаться обширной зоной покрытия. LTE сегодня присутствует только в ряде крупных городов страны.
LTE и 4G
Оба стандарта относятся к одному поколению, они имеют ряд отличий. Эти технологии нельзя считать одним и тем же.
В чём разница, у LTE по сравнению с 4G:
Плюсы использования в телефонах и планшетах
Какие преимущества для пользователей несёт внедрение новых стандартов связи?
Увеличение скорости передачи данных способствует расширению услуг и снижению их стоимости.
Какие операторы предоставляют в России
Все ведущие компании предоставляют абонентам такую возможность. Также операторы снабжают пользователей модемами и карманными роутерами, для доступа в сеть.
Как подключиться к LTE
Если смартфон поддерживает LTE, то для подключения достаточно иметь правильно настроенную точку доступа. Как только гаджет окажется в зоне покрытия 4G, он автоматически переключится на высокоскоростную сеть.
Ряд моделей смартфонов отлично переключится на LTE, но как только покидают зону покрытия не могут самостоятельно вернуться к 3G. Они не видят сети, и чтобы вновь появилась возможность использования интернета необходимо перезагрузить устройство.
Русские Блоги
LTE Attach
Конкретный процесс потока сообщений по-прежнему соответствует 3GPP 23.401. Объясните некоторые процессы и конкретные сообщения процесса прикрепления. И дайте соответствующий нормативный источник.
1. Во-первых, первое начальное сообщение Attach: судя по конкретному пакету wirehark, это начальное вложение содержит два события: attach Req + PDN connectivity Req
Attach Req Само собой разумеется, что это необходимый процесс для входа терминала в сеть. Появление PDN Conncetivity Req должно установить носитель по умолчанию.
В спецификации NAS 24.301 6.5.1.1 четко указано, что PDN Con Req, включенный в запрос на присоединение, предназначен для первоначального установления канала-носителя по умолчанию (это не зависит от канала-носителя по умолчанию, который может быть установлен с другими APN). В этом PDN Connect Req стороне UE не нужно предоставлять адрес APN.Другими словами, APN, к которому подключен этот исходный канал по умолчанию, должен определяться сетевой стороной. Терминал предоставляет только типы IP-адресов, поддерживаемые UE. Чтобы
(Но есть исключения. Хотя это требуется в спецификации, есть также мнения, что APN UE больше соответствует бизнес-потребностям UE. Например, если UE хочет напрямую подключиться к корпоративной сети, UE должно предоставить APN, но это APN предоставляется После того, как аутентификация и сопоставление безопасности NAS установлены, предоставление APN по умолчанию должно быть оценено в соответствии с фактической реализацией бизнеса оператора или потребностями клиента)
When the PDN CONNECTIVITY REQUEST message is sent together with an ATTACH REQUEST message, the UE
shall not include the APN.
Рассмотрение привязки PDN Connectivity Req и Attach Req взято из 3GPP2 24.301, 4.2 Идея IP-адреса UE alwanys online реализована в LTE.
а. Внимательно посмотрите на тело сообщения. В этом сообщении на уровне S1AP на данный момент присутствует только значение eNB-UE-S1AP-ID, а идентификатор S1AP на стороне сети должен ждать ответа MME.
б) На уровне NAS (как показано на рисунке 2): сообщение о мобильности EPS появляется дважды. Сообщение ESM PDN Connet Req включено в сообщение EMM, которое через IE контейнера сообщений ESM содержит содержимое ESM.
Позже, в зависимости от каждого сообщения NAS, само сообщение NAS имеет тип IEI дискриминатора протокола и заголовка безопасности, поэтому заголовок сообщения управления мобильностью EPS появляется дважды. (Но почему он появляется дважды? Разве заголовка безопасности конкретного сообщения NAS недостаточно? Зачем добавлять еще один уровень заголовка безопасности?)
Затем, если действительный контекст безопасности NAS уже существует на стороне UE, UE необходимо установить Intergrity Protect в приложении Req. Соответствует 3GPP 24301:
1) Except for the case described in item 3 below, the UE shall transmit the initial NAS message integrity protected with the current EPS security context, but unciphered. The UE shall include the eKSI indicating the current EPS security context value in the initial NAS message. The MME shall check whether the eKSI included in the initial
NAS message belongs to an EPS security context available in the MME, and shall verify the MAC of the NAS message. If the verification is successful, the MME may re-establish the secure exchange of NAS messages:
— by replying with a NAS message that is integrity protected and ciphered using the current EPS security context. From this time onward, all NAS messages exchanged between the UE and the MME are sent integrity protected and except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the MME are sent ciphered; or
— by initiating a security mode control procedure. This can be used by the MME to take a non-current EPS security context into use or to modify the current EPS security context by selecting new NAS security algorithms;
И контекст безопасности отмечен NAS COUNT. Счетчик NAS соответствует заголовку NAS, который является порядковым номером. MME использует порядковый номер для поиска соответствующего контекста безопасности (если он существует), а затем использует код аутентификации сообщения для завершения проверки.
c. Затем откройте IEI контейнера сообщений ESM.
можно увидеть:
В теле сообщения стоит отметить следующие заголовки: идентификатор носителя EPS, идентификатор транзакции процедуры. Чтобы
Идентификатор канала-носителя EPS используется для идентификации потока сообщений. Идентификатор носителя EPS в этом NAS соответствует идентификатору контекста носителя, установленному на GTP-C.
Procedure transaction： A L3 protocol may define that the second octet of a standard L3 message of the protocol contains the proceduretransaction identity (PTI). The PTI allows distinguishing up to 254 different bi-directional messages flows for a given PD and a given SAP. Such a message flow is called a transaction. The procedure transaction identity is released when the procedure is completed.
Для применения этих двух хедеров в LTE 24.301 дает подробное описание. См. 6.3.2.
И, судя по модели маршрутизации в 24.007, PTI + PD используется EMM для маршрутизации сообщений в ESM. Как только контекст канала-носителя установлен и ESM может выделить идентификатор контекста, последующие сообщения не требуют PTI.
Например: запрос контекста PDN (от UE к MME) требует PTI, требование носителя по умолчанию для EPS (от MME к UE) требует (PTI, EBI), а последующий ответ на несущий канал по умолчанию EPS (от UE к MME) требует только EBI Теперь PTI не нужен.
В этом процессе уровень EMM должен предоставлять услугу маршрутизации для ESM. EMM использует PTI, чтобы различать и устанавливать различные транскрипции для ESM. После того, как MME получает req, возвращаемое значение Bearer Req по умолчанию также нуждается в PTI, потому что ему необходимо UE указало, что оно выделило EBI для предыдущей транзакции ESM. После того, как UE получило его, две стороны достигли консенсуса по ESM, и сотрудничество PTI не требуется, поскольку уникальность идентификатора Bearer ID достаточна для EMM в последующем процессе. Направьте сообщение ESM на соответствующий уровень EMS для обработки.
2) Новый MME затем запрашивает у UE получение IMSI, и MME может запрашивать у HSS данные аутентификации и последующие данные пользователя на основе IMSI. Но в настоящее время, поскольку режим безопасности не установлен, сообщение уровня NAS
Обычное сообщение NAS, не защищенное системой безопасности, также следует рассматривать как опасное место.
3) После того, как MME получает IMSI, он завершает пятикратное взаимодействие аутентификации с HSS через AIR / AIA диаметра.
4) MME отправляет значение RAND и AUTN в UE, запрашивая UE сообщить данные аутентификации.
5) MME принимает ответ аутентификации NAS и после прохождения аутентификации начинает установку режима безопасности.
Согласно положениям 4.4.2.4 в 24.301,
The SECURITY MODE COMMAND message sent by the MME includes the eKSI of the new EPS security context to be used. The MME shall send the SECURITY MODE COMMAND message integrity protected with the new EPS security context, but unciphered. When the UE responds with a SECURITY MODE COMPLETE, it shall send the message integrity protected and ciphered with the new EPS security context.
Команда безопасности, выдаваемая MME, защищена только целостностью и не зашифрована, однако последующее сообщение Security Complete UE должно быть зашифровано.
Но если MME выбирает «нулевой алгоритм шифрования» EEA0 для правила шифрования, хотя NAS между UE и MME не передает шифр, заголовок безопасности также должен быть зашифрован.
(См. 24.301-4.4.5, «Если в качестве алгоритма шифрования был выбран« нулевой алгоритм шифрования »EEA0, сообщения NAS с заголовком безопасности, указывающим на шифрование, считаются зашифрованными»)
Конкретное изображение: (Я до сих пор не понимаю, почему нам нужно вставлять заголовок безопасности двух уровней EMM. Заголовок безопасности первого уровня можно понять, но для конкретного EMM, почему второму уровню нужен заголовок безопасности? Он включен напрямую. Разве это не на первом этаже?)
Продолжая последнюю тему, перейдите к MME, чтобы запросить пользовательские данные, такие как HSS, с помощью процесса Diameter ULR / ULA.
ULR не имеет большого описания. Сосредоточьтесь на анализе ULA. Технические характеристики относятся к 3gpp 29272, 23401
Для AVP ULA наиболее важные пользовательские данные находятся в Subscription-Data.
from 23401.5.3.2.1 step 11:
The Subscription Data contain one or more PDN subscription contexts. Each PDN subscription context contains an ‘EPS subscribed QoS profile’ and the subscribed APN-AMBR (see clause 4.7.3).
Затем щелкните AVP APN-Configuraion с идентификатором контекста 2, чтобы увидеть:
Этот IE должен содержать APN для выбранного и динамически распределенного PDN GW. Он должен присутствовать, если выбранный PDN-GW присутствует и является специфическим для одной конкретной APN, а не общим для всех APN. Это также повторяет HSS для носителя по умолчанию. Предоставленный APN не может быть APN дикого типа.
И это значение является сетевым идентификатором APN, а последующий идентификатор операции составляет завершенное APN, которое используется для запроса NAPTR / AAA для получения адреса PGW.
Я плохо понимаю последующий QOS-Profile. QCI легко понять, но сцена Allocation-Retention-Priority еще не понятна.
The VPLMN Dynamic Address Allowed AVP is of type Enumerated. It shall indicate whether for this APN, the UE is allowed to use the PDN GW in the domain of the HPLMN only, or additionally, the PDN GW in the domain of the VPLMN.. If this AVP is not present, this means that the UE is not allowed to use PDN GWs in the domain of the VPLMN.
Имеет ли этот абзац отношение к более позднему выбору PGW? Или PGW VPLMN будет подключаться к PGW HPLMN?
(Кроме того, из pcpa на месте, если APN, запрошенная мобильным телефоном при подключении, не является адресом APN по умолчанию в данных подписки HSS, то MME будет следовать APN UE, чтобы установить канал передачи по умолчанию вместо использования данных подписки HSS)
При нормальных обстоятельствах MME должен по-прежнему использовать APN-Configuraion-Profile по умолчанию, чтобы установить канал-носитель по умолчанию для UE. После того, как MME использует DNS-запрос для завершения выбора PGW, он запускает процесс установления туннеля.
В этом параграфе начинается описание процесса установления туннеля между MME, SGW и PGW. В основном используйте Create Session Req / Resp для канала-носителя по умолчанию и Create Bearer Request / Resp для настройки выделенного канала-носителя.
so, 1st one is MME send to SGW the Create Session Req, the message sample is :
The more important things are t he Fully Qualified Tunnel Endporint Identifier (F-TEID), PCO, and the Bearer Context.
SGW will do the Create Session REQ/RESP towards the IP of PGW. so that the TEID is «0» for the PGW, Need to wait the PGW to assign the value.
About the PCO (Ptorocol Configuration Options )
The purpose of the Protocol Configuration Options (PCO) is to provide additional optional information about the destination network that the UE is connecting to. For example, when a UE connects to the Internet it will be given an IP address and it will be given a PCO that includes the default gateway IP address, the DNS server address, etc. All of these additional pieces of information are given in the PCO.
for the IMS accsss, the UE need to get the PCSCF address.
for the internet access, the UE need to get the DNS service ip address.
for the Bearer Context: MME only assign a EBI, others value need the PGW to assign ( by the Policy and Charging rule from PCRF)
2nd one is the Create Session Req from SGW to PGW, most of message header and value are same as the 1st one sent from MME to SGW.
Except: The TEID AND IP for Control Plane are changed to SGW,
And in the Bearer Context: there is the TEID and IP of SGW towards PGW for User-Plane.
На этом этапе MME и SGW предоставили TEID и IP, которые будут использоваться в канале плоскости сигнализации нисходящей линии связи, а SGW также предоставил TEID и IP плоскости пользователя, которые будут использоваться в канале нисходящей линии связи.
Продолжая с прошлого раза, MME и SGW начали прокладывать туннели. Теперь очередь PGW. При отправке ответа на создание сеанса PGW необходимо запросить данные пользователя у PGW.
Стандартизируйте 3gpp 23203, 3gpp 29210, 3gpp 29212.
Согласно 23203Архитектура, PGW (PCEF) запрашивает пользовательские данные о правилах политики и обмена из PCRF. (Это конкретно относится к использованию динамических правил; предопределенные правила предварительно определены на PGW, и нет необходимости использовать GXinterface).
Поскольку AF не имеет соответствующего процесса pcap, здесь он описываться не будет.
The Policy and charging control rule (PCC rule) comprises the information that is required to enable the user plane detection of, the policy control and proper charging for a service data flow. The packets detected by applying the service data flow template of a PCC rule are designated a service data flow.
Что касается информации, передаваемой в PCEF и PCRF, то они перечислены на странице 23.203 58.
Просто посмотрите на AVP в сообщении CCR:
Default-EPS-Bearer-QoS в CCR:
When this AVP is sent from the PCEF to the PCRF, it indicates the subscribed QoS for the default EPS bearer and/or the retained QoS for the default EPS bearer in the PCEF. When this AVP is sent from the PCRF to the PCEF, it indicates the authorized QoS for the default EPS bearer.
Соответствующий заголовок AVP: Charing-Rule-Install, Qos-Inforamtion, Default-EPS-Bearer-Qos:
Содержимое QOS, TFT и правила зарядки, о которых мы заботимся, устанавливается в AVP-файле Charging-Rule-Install. Щелкните этот AVP, чтобы увидеть:
Существует два правила смены, каждое с другим именем правила, и также указан метод начисления платы (Enable-offline). Flow-Description также дает значение порта фильтра восходящего и нисходящего каналов для генерации TFT.
Потому что из другой AVP: Default-EPS-Bearer-QOS можно увидеть, что эта AVP дает QCI, используемый Default Bearer. В то время этот QCI может быть таким же, как QCI в Charing-Rule-Install ранее, но значение другое.
1. QOS и OCI, требуемые Default-Bearer, также могут рассматриваться как профиль пользователя в Charing-RULE, и, конечно, они также должны быть включены в Charging-Rule.
2. Для Default-Bearer будут другие IP-пакеты, поэтому эта часть информации о начислении платы и требований также будет включена в правило начисления платы. Чтобы
Поэтому, хотя содержимое Default-EPS-Bearer-Qos кажется частично скопированным из Charing-Rule, специально отмечено, что часть используется как носитель по умолчанию.
Что касается Event-Trigger, то здесь разобраться проще. Определяет обстоятельства, при которых QOS изменится, и сторонам необходимо снова провести переговоры.
Наконец-то эта часть закончена. Вроде лучше картинку нарисовать.
Прохождение вызовов в сети VoLTE (call flow)
Регистрация и активация дефолтного виртуального соединения
Начальная регистрация (EPS attach) выполняется при включении пользователем абонентского терминала (UE) в зоне действия сети LTE. Рассмотрим ситуацию, когда пользовательский терминал является voice-centric.
UE активирует RRC соединение и переходит в состояние RRC_CONNECTED.
UE инициирует процедуру присоединения к сети (EPS attach), путем направления в сторону eNodeB запроса attach request.
Данное сообщение содержит информацию о возможностях и предпочтения UE в части голосовых услуг, например,
Далее eNodeB перенаправляет запрос attach request в выбранный MME посредством S1-MME интерфейса.
MME инициирует процедуру аутентификации UE, запрашивая векторы аутентификации в HSS/AUC.
MME направляет в HSS запрос на обновление местоположения (update location request) соответствующей абонентской записи с указанием IMSI.
HSS (при наличии соответствующей подписки абонента на услуги) отвечает MME на запрос обновления местоположения (update location acknowledgement message). При этом на MME передаются параметры пакетного соединения для доступа к IMS, включая параметры дефолтного виртуального соединения (bearer), используемого для переноса сигнального SIP трафика. Например,
Для VoLTE абонентов APN по умолчанию должен быть APN для доступа к IMS.
Основываясь на информации, полученной от HSS, а также локальной конфигурации, MME выполняет проверку параметров поддержки голосовых услуг абонентским терминалом (UE voice capabilities), APN, параметров QoS, наличие роуминговых ограничений. Далее MME выбирает обслуживающий шлюз (S-GW) и пакетный шлюз (P-GW). При этом S-GW выбирается на основе местоположения пользовательского терминала UE; P-GW – на основе APN (для обслуживания голосовых вызовов может быть установлен выделенный P-GW, размещенный рядом с медиашлюзом IM-MGW). После выбора S/P-GW MME направляет в выбранный P-GW запрос на создание сессии (creation session request), инициируя создание виртуального соединения (bearer) по умолчанию. S-GW перетранслирует данный запрос в P-GW.
P-GW создает в таблице контекстов виртуальных соединений (EPS bearer context table) новую запись для маршрутизации пользовательского трафика между S-GW и пакетной сетью (PDN), после чего направляет S-GW отклик на запрос о создании сессии (Create Session Response), который далее перетранслирует его MME. Отклик включает идентификатор созданного виртуального соединения по умолчанию (default EPS bearer identification), QoS параметры, IP адреса UE и P-CSCF. При этом адрес P-CSCF передается в опциях конфигурации протокола (PCO – protocol configuration options).
MME проверяет существующие модификации для установления потока по умолчанию и определяет UE-AMBR, основываясь на APN-AMBR. Если на шаге 2 пользовательский терминал (UE) выполнил запрос процедуры комбинированной регистрации в сети (combined EPS/IMSI attach), в т.ч. для обеспечения CSFB, MME направляет запрос на обновление местоположения (location update request) к MSC/VLR CS домена. MME завершает регистрацию в сети сообщением UE (через eNodeB) об успешном выполнении процедуры (attach accept) и одновременно инициирует процедуру установки начального UE контекста в eNodeB посредством запроса Initial Context Setup Request. Запрос включает финальную индикацию поддержки сервиса голосовой связи через IMS PS домен (IMS voice over PS session), а также параметры созданного виртуального соединения (bearer), например,
UE также получает список идентификаторов зон местоположения (TAI), в пределах которых пользовательский терминал может перемещаться без обновления информации о своем местоположении в MME. При этом индикация поддержки сервиса голосовой связи через IMS PS домен (IMS voice over PS session) действительна только в пределах обозначенного списка зон местоположения и может отличаться при выходе пользовательского терминала за их пределы.
Завершение процедуры реконфигурации радиосоединения (RRC reconfiguration).
eNodeB выполняет процедуру установки начального UE контекста и направляет соответствующий отчет в MME посредством сообщения Initial Context Setup Response.
UE посылает к eNodeB сообщение attach complete в составе direct transfer message, включающее идентификатор виртуального соединения (EPS bearer identity) и порядковый номер сообщений NAS (NAS SQN), которое в дальнейшем переправляется eNodeB к MME в сообщении в uplink NAS transport message.
Пользовательский терминал (UE) теперь может посылать UL пакеты по направлению к eNodeB, который будет туннелировать их к S/P-GW.
MME посылает к S-GW запрос модификации виртуального соединения (bearer) в соответствии с принятыми параметрами.
S-GW подтверждает модификацию виртуального соединения (bearer) посредством сообщения modify bearer response к MME. Виртуальные соединения (bearer) к этому моменту установлены и готовы к переносу UL и DL пакетов.
Регистрация в IMS
Пользовательский терминал (UE) формирует и направляет сообщение REGISTER в направлении P-CSCF домашней сети. Адрес P-CSCF пользовательский терминал (UE) получает из сети в блоке PCO (Protocol Configuration Options) NAS PDU (либо иным способом). Сообщение передается в открытом виде (до активации IPSec ассоциации).
Пример сообщения REGISTER приведен ниже.
REGISTER sip:310410010001002@ims.mnc410.mcc310.3gppnetwork.org SIP/2.0
Via: SIP/2.0/TCP [fd00:183:1:1:1886:9040:8605:32b8]:5060;branch=z9hG4bKVT3F3PbXtxKWEdp;rport
Max-Forwards: 70
Expires: 600000
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=31041000011a2d001
From: ;tag=cVKbrkhG0L
To:
Contact:
Contact URI: sip:[fd00:183:1:1:1886:9040:8605:32b8]:5060
Contact parameter: +g.3gpp.icsi-ref=»urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel»
Contact parameter: +g.3gpp.smsip
Contact parameter: +sip.instance=» «\r\n
Call-ID: 5PC5dBCGDQ0csFmFPQXQjE57
Authorization:
Authentication Scheme: Digest
Nonce Value: «»
Authentication URI: «sip:310410010001002@ims.mnc410.mcc310.3gppnetwork.org»
Realm: «310410010001002@ims.mnc410.mcc310.3gppnetwork.org»
Username: «263734@imstest.lan»
Digest Authentication Response: «»
Security-Client: ipsec-3gpp;alg=hmac-md5-96;ealg=aes-cbc;mod=trans;port-c=49246;port-s=49247;prot=esp;spi-c=110322342;spi-s=265410654,ipsec-3gpp;alg=hmac-md5-96;ealg=des-ede3-cbc;mod=trans;port-c=49246;port-s=49247;prot=esp;spi
Require: sec-agree
Proxy-Require: sec-agree
CSeq: 9 REGISTER
Allow: ACK,BYE,CANCEL,INVITE,MESSAGE,NOTIFY,OPTIONS,PRACK,REFER,UPDATE
Supported: 100rel,path,replaces
User-Agent: iOS/8.1 (12B411) iPhone
Content-Length: 0
Основные заголовки и параметры сообщения:
P-CSCF, получив запрос REGISTER, выполняет следующие действия:
I-CSCF выполняет следующие действия:
S-CSCF выполняет следующие действия:
P-CSCF, получив отклик «401 (Unauthorized)», направляет его пользовательскому терминалу (UE), предварительно удалив из него ключи шифрования и контроля целостности.
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP [fd00:183:1:1:1886:9040:8605:32b8]:5060;branch=z9hG4bKVT3F3PbXtxKWEdp;rport=5060;received=fd00:183:1:1:1886:9040:8605:32b8
From: ;tag=cVKbrkhG0L
To:
CSeq: 9 REGISTER
WWW-Authenticate:
Authentication Scheme: Digest
Realm: «310410010001002@ims.mnc410.mcc310.3gppnetwork.org»
Nonce Value: «PUKFeHLm/11FH3TWcJQkNO4fvEgFDZAB9hGpnv8tWi8=»
Algorithm: AKAv1-MD5
Security-Server: ipsec-3gpp;alg=hmac-md5-96;ealg=aes-cbc;mod=trans;port-c=5062;port-s=5063;prot=esp;spi-c=3333;sip-s=4444
Server: YATE/5.4.1
Allow: ACK, INVITE, BYE, CANCEL, REGISTER, OPTIONS, UPDATE, PRACK, INFO, MESSAGE, SUBSCRIBE
Content-Length: 0
Пользовательский терминал (UE) при получении отклика «401 (Unauthorized)» посредством абонентского модуля ISIM (USIM):
Далее устанавливается IPSec ассоциация между UE и P-CSCF, после чего пользовательский терминал инициирует вторую фазу IMS регистрации. UE создает второй запрос REGISTER (защищенный IPSec), который маршрутизируется по маршруту, аналогичному исходному. Запрос содержит новые номер «CSeq», параметр «branch», а также параметр «tag» заголовка «From». Кроме того, в запрос включается информация аутентификации:
REGISTER sip:310410010001002@ims.mnc410.mcc310.3gppnetwork.org SIP/2.0
Via: SIP/2.0/TCP [fd00:183:1:1:1886:9040:8605:32b8]:5060;branch=z9hG4bKVT3F3PbXtxKWEdp;rport
Max-Forwards: 70
Expires: 600000
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=31041000011a2d001
From: ;tag=cVKbrkhG0L
To:
Contact:
Contact URI: sip:[fd00:183:1:1:1886:9040:8605:32b8]:5060
Contact parameter: +g.3gpp.icsi-ref=»urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel»
Contact parameter: +g.3gpp.smsip
Contact parameter: +sip.instance=» «\r\n
Call-ID: 5PC5dBCGDQ0csFmFPQXQjE57
Authorization:
Authentication Scheme: Digest
Nonce Value: «PUKFeHLm/11FH3TWcJQkNO4fvEgFDZAB9hGpnv8tWi8=»
Authentication URI: «sip:310410010001002@ims.mnc410.mcc310.3gppnetwork.org»
Username: 263734@imstest.lan
Algorithm: AKAv1-MD5
Realm=»310410010001002@ims.mnc410.mcc310.3gppnetwork.org»
Digest Authentication Response: «74482d7d5fac29480469aa2dd85e3c1d»
Security-Client: ipsec-3gpp;alg=hmac-md5-96;ealg=aes-cbc;mod=trans;port-c=49248;port-s=49249;prot=esp;spi-c=213693184;spi-s=158855190,ipsec-3gpp;alg=hmac-md5-96;ealg=des-ede3-cbc;mod=trans;port-c=49248;port-s=49249;prot=esp;spi
Require: sec-agree
Proxy-Require: sec-agree
CSeq: 10 REGISTER
Allow: ACK,BYE,CANCEL,INVITE,MESSAGE,NOTIFY,OPTIONS,PRACK,REFER,UPDATE
Supported: 100rel,path,replaces
User-Agent: iOS/8.1 (12B411) iPhone
Content-Length: 0
P-CSCF добавляет поле «integrity-protected» со значением yes в заголовок «Authorization» и пересылает запрос в I/S-CSCF.
S-CSCF получив запрос REGISTER от пользовательского терминала (в рамках второй фазы регистрации) сравнивает значение параметра RES, полученное от UE со значением XRES, полученным от HSS и в случае их идентичности аутентифицирует терминал. При этом создается связка публичного идентификатора пользователя (PuUI), полученного в заголовке «To» запроса и сетевого адреса, полученного в заголовке «Contact». Далее S-CSCF обновляет данные о регистрации UE в HSS и загружает из него пользовательский профиль.
Для подтверждения регистрации S-CSCF отправляет пользовательскому терминалу отклик 200 (OK). Сообщение маршрутизируется через все CSCF, через которые был получен запрос REGISTER (в соответствии с листом, содержащимся в параметре «Via»). Отклик 200 (OK) включает в т.ч. заголовок P-Associated-URI, содержащий перечень зарегистрированных за данным UE публичных идентификаторов пользователя (PuUI), в дополнение к полученному в запросе REGISTER:
SIP/2.0 200 OK
Via: SIP/2.0/TCP [fd00:183:1:1:1886:9040:8605:32b8]:5060;branch=z9hG4bK0iTZW12JDCCkuJn;rport=5060;received=fd00:183:1:1:1886:9040:8605:32b8
From: ;tag=1QGDmSrhTP
To: ;tag=497094864
Call-ID: 5PC5dBCGDQ0csFmFPQXQjE57
CSeq: 10 REGISTER
Expires: 3600
Contact:
Contact URI: sip:[fd00:183:1:1:1886:9040:8605:32b8]:5060
Contact parameter: expires=3600
Authentication-Info: rspauth=»74482d7d5fac29480469aa2dd85e3c1d», mode=»IMS»
Security-Server: ipsec-3gpp;alg=hmac-md5-96;ealg=aes-cbc;mod=trans;port-c=5062;port-s=5063;prot=esp;spi-c=3333;sip-s=4444
P-Associated-URI:
Server: YATE/5.4.1
Allow: ACK, INVITE, BYE, CANCEL, REGISTER, OPTIONS, UPDATE, PRACK, INFO, MESSAGE, SUBSCRIBE
Content-Length: 0
Third-Party Registration to Application Servers
После успешной регистрации в S-CSCF требуется регистрация пользователей во всех серверах приложений (AS), которые могут быть подключены к обработке вызовов (в соответствии с установленными для пользователя критериями фильтрации). Для этого S-CSCF генерирует и направляет к серверам приложений (включая TAS) запросы third-party REGISTER. В данных запросах:
S-CSCF может также вложить в third-party REGISTER тело исходного запроса.
В ответ на third-party REGISTER сервер приложений отвечает в S-CSCF сообщением 200 (OK), однако при этом AS не выполняет функцию SIP-REGISTRAR, а использует запрос как подтверждение того, что пользователь успешно зарегистрировался в S-CSCF.
Subscription to Registration Event Package
После завершения регистрации UE, P-CSCF (а также опционально AS) выполняют процедуру подписки на пакет событий о статусе регистрации. Это обеспечивает получение запросов инициируемой сетью ре-аутентификации (network initiated re-authentication) и инициируемой сетью де-регистрации (network initiated de-registration). В дополнение подписка на пакет событий о статусе регистрации обеспечивает передачу информацию о статусе всех публичных идентификаторов пользователя (PuUI).
Re-Registration and Re-Authentication
S-CSCF может изменить значение таймера регистрации, изначально предложенное пользовательским терминалов в заголовке «Contact» (например, уменьшение таймера с целью безопасности, т.к. процедура аутентификации «привязана» к процедуре регистрации). Обновление таймера регистрации выполняется как часть пакета событий о статусе регистрации на который должен быть подписан пользовательский терминал (а также P-CSCF, AS) посредством запроса NOTIFY.
De-Registration
Де-регистрация пользовательского терминала в сети IMS может выполняться в двух сценариях:
VoIP сессия в IMS
Диаграмма установления соединения (Call Flow) между двумя пользователями сети IMS (в общем случае, принадлежащими различным доменам) показана на рисунке ниже.
Начинается диалог с запроса INVITE, который включает в себя блок информации SIP и блок информации SDP (session description protocol – протокол описания сессии). Последний используется для согласования медиа-компонентов (в данном случае – аудио компонентов).
Структура запроса INVITE
Структура блока SIP информации:
Структура блока SDP информации:
Параметры описания сессии (Session Description):
информация об организаторе сессии и её ID:
Описание времени (Time Description)
Описание медиа параметров (Media Description)
– номер транспортного порта, на который будет посылаться трафик;
Маршрутизация вызова
Пользовательский терминал вызывающего абонента (UE-A) имеет следующую маршрутную информацию:
Рассмотрим основные шаги обработки вызова:
Таким образом, на этапе маршрутизации запроса INVITE от абонента «A» к абоненту «B» сообщение последовательно транслируется от одного узла к другому. При этом каждый предыдущий хоп владеет только информацией о следующем хопе, и не знает о дальнейшем маршруте. Для упрощения маршрутизации последующих сообщений в рамках диалога протоколом SIP предусмотрены следующие механизмы:
и отправляет сообщение на адрес/порт из вершины стека «Via», который является защищенным портом прокси P-CSCF.
В дальнейшем, когда любому из пользовательских терминалов (UE) требуется отправить какой-либо запрос в рамках текущего диалога он копирует список хопов (сохраненных на предыдущем шаге из заголовка «Record-Route») в заголовок «Route» и IP адрес удаленного UE в «Request URI», обеспечивая тем самым идентичность маршрута всех запросов в рамках одного диалога. Идентичность маршрута отклика маршруту запроса обеспечивается посредством работы со стеком адресов заголовка «Via».
В последующие запросы (в рамках одного диалога) не включается заголовок «Contact», поскольку пользовательские терминалы (UE) уже обменялись информацией о своих адресах в рамках первичных запроса и отклика. Аналогично не включаются в запросы заголовки Record-Route, поскольку маршрут следования был зафиксирован и сохранен в рамках первичного запроса.
Рисунки ниже визуализируют ранее описанные общие принципы маршрутизации.
Рис. 53 (Принципы маршрутизации начального запроса и его отклика):
Рис. 54 (Принципы маршрутизации последующего запроса и его отклика):
Согласование медиа-ресурсов
Вернемся к блоку SDP, переданному в запросе INVITE, при этом рассмотрим только часть SDP параметров, а именно – медиа-данных («m линии») и соответствующие им линии атрибутов медиа-данных («a линии») – см. ниже.
Media Description, name and address (m):
Media Type: audio
Media Port: 49120
Media Protocol: RTP/AVP
Media Format: DynamicRTP-Type-104
Media Format: DynamicRTP-Type-110
Media Format: DynamicRTP-Type-102
Media Format: DynamicRTP-Type-108
Media Format: DynamicRTP-Type-105
Media Format: DynamicRTP-Type-100
Media Attribute (a): rtpmap:104 AMR-WB/16000
Media Attribute (a): fmtp:104 octet-align=0; max-red=0
Media Attribute (a): rtpmap:110 AMR-WB/16000
Media Attribute (a): fmtp:110 octet-align=1; max-red=0
Media Attribute (a): rtpmap:102 AMR/8000
Media Attribute (a): fmtp:102 octet-align=0; max-red=0
Media Attribute (a): rtpmap:108 AMR/8000
Media Attribute (a): fmtp:108 octet-align=1; max-red=0
Media Attribute (a): rtpmap:105 telephone-event/16000
Media Attribute (a): fmtp:105 0-15
Media Attribute (a): rtpmap:100 telephone-event/8000
Media Attribute (a): fmtp:100 0-15
Первая «m-линия» индицирует, что вызывающий пользователь (UE-A) запрашивает в рамках созданной сессии обмен аудио данными с использованием локального порта 49120. В качестве транспортного протокола для трафика аудио данных будет использоваться RTP / AVP (Real-time transport protocol / audio video profile).
При этом возможна передача:
Посредством ранее описанных механизмов маршрутизации блок SDP от UE-A в составе запроса INVITE доставляется вызываемому абоненту (UE-B), который осуществляет согласование медиа-характеристик, формирует ответный блок SDP и в составе сообщения 183 (Session Progress) возвращает его вызывающему абоненту.
Резервирование медиа-ресурсов и управление политиками
Технология «Voce over LTE» подразумевает перенос голосового медиа-трафика через выделенное виртуальное соединение (dedicated bearer) с QCI 1 и гарантированной битовой скоростью (GBR), что фактически означает резервирование ресурсов до конечного пользовательского терминала (UE). Выделенное виртуальное соединение создается только на время длительности голосового вызова. При этом до резервирования ресурсов и создания dedicated bearer пользовательские терминалы (UE) не могут начать передачу медиа трафика.
Для удовлетворения вышеописанным требованиям в RFC3312 был специфицирован так называемый механизм предварительных условий (precondition mechanism), который позволяет UE задерживать установление SIP сессии до окончания процесса резервирования ресурсов на обеих сторонах. Расширение RFC3312 обязательно для всех пользовательских IMS терминалов.
Для иллюстрации механизма резервирования медиа-ресурсов рассмотрим часть SDP параметров, которые необходимы для установления dedicated bearer:
Индицирует, что состояние обмена медиа-трафиком – неактивно. До получения индикации об активности удаленная сторона не должна генерировать трафик.
a=curr:qos local none
Индицирует текущий статус резервирования ресурсов на локальной стороне (на стороне UE-A) – ресурсы не зарезервированы..
a=curr:qos remote none
Индицирует текущий статус резервирования ресурсов на удаленной стороне (на стороне UE-B) – ресурсы не зарезервированы.
a=des:qos mandatory local sendrecv
Индицирует требования к резервированию ресурсов, запрашиваемые вызывающим абонентом на локальной стороне (на стороне UE-A):
a=des:qos none remote sendrecv
Индицирует требования к резервированию ресурсов, запрашиваемые вызывающим абонентом на удаленной стороне (на стороне UE-B):
1. В случае, если пользовательский терминал вызываемого абонента (UE-B) также подключен к сети LTE и поддерживает механизм предварительных условий (precondition mechanism) в соответствии с RFC3312, при получении от пользовательского терминала вызывающего абонента (UE-A) запроса на установление сессии с блоком SDP должен сформировать на него ответ, указав собственные предварительные условия, и передать его в отклике 183 (Session Progress):
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o):
Owner Username: yate
Session ID: 1415985490
Session Version: 1415985490
Owner Network Type: IN
Owner Address Type: IP6
Owner Address: fd00:183:1:1:1886:9040:8605:43c9
Session Name (s): SIP Call
Connection Information (c):
Connection Network Type: IN
Connection Address Type: IP6
Connection Address: fd00:183:1:1:1886:9040:8605:43c9
Time Description, active time (t):
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m):
Media Type: audio
Media Port: 49540
Media Protocol: RTP/AVP
Media Format: DynamicRTP-Type-102
Media Format: DynamicRTP-Type-100
Bandwidth Information (b): AS:49
Bandwidth Modifier: AS [Application Specific (RTP session bandwidth)]
Bandwidth Value: 49 kb/s
Bandwidth Information (b): RS:0
Bandwidth Information (b): RR:0
Media Attribute (a): rtpmap:102 AMR/8000
Media Attribute (a): fmtp:102 octet-align=0
Media Attribute (a): rtpmap:100 telephone-event/8000
Media Attribute (a): inactive
Media Attribute (a): des:qos mandatory local sendrecv
Media Attribute (a): curr:qos local none
Media Attribute (a): des:qos mandatory remote sendrecv
Media Attribute (a): curr:qos remote none
Media Attribute (a): conf:qos remote sendrecv
По сравнению с запросом вызывающий и вызываемый пользователи поменяны местами (UE-A – remote, UE-B – local). Также присутствует строка, неописанная выше (a=conf:qos remote sendrecv) и означающая, что UE-A должен отправить подтверждение резервирования ресурсов. Необходимость данной строки обусловлена тем, что UE-B не оповещает вызываемого пользователя о поступившем вызове и не генерирует медиа поток до резервирования ресурсов на обеих сторонах.