Регистрация в сети LTE (UE Attach)
В начале работы мобильная станция (МС) должна выполнить регистрацию в сети для того, чтобы получить возможность пользоваться различными сервисами (в том числе и обмениваться данными). В рамках процедуры подключения к сети также создается соединение, сконфигуренное по умочанию, и устанавливается прямое IP соединение с PDN шлюзом.
Перед регистрацией в EPC мобильная станция должна «подружиться» с базовой станцией (БС). Данная процедура называется созданием RRC соединения (RRC Connection Establishment) и сопровождается изменением состояния МС с RRC_IDLE на RRC_CONNECTED. В начале этой процедуры МС осуществляет синхронизацию с БС, используя первичный и вторичный сигналы синхронизации (PSS и SSS). После синхронизации МС слушает канал PBCH (Physical Broadcast Channel), в котором передается MIB (Master Information Block), где указываются основные характеристики сети (ширина канала, текущий номер кадра и формат PHICH канала).
После отправки сообщения ‘RRC Connection Request’ МС запускает таймер Т300 (его значение сообщается в SIB2 и может принимать следующие величины: 100, 200, 300, 400, 600, 1000, 1500, 2000 мс). В LTE не предусмотрено повторных передач сообщения ‘RRC Connection Request’. Поэтому, если таймер Т300 истекает до получения ответа от БС, то процедура завершается с ошибкой. При отправке сообщения ‘RRC Connection Request’ может возникнуть коллизия (когда две или более МС выберут одну и ту же RACH преамбулу для передачи в одном и том же подкадре). В этом случае, МС будет повторно передавать сначала RACH преамбулу, а потом и сообщение ‘RRC Connection Request’. Из-за чего общее время создания соединения может увеличиться.
После успешной передачи сообщения ‘RRC Connection Request’ мобильной станцией, БС передает сообщение ‘RRC Connection Setup’. Так как МС уже успешно завершила процедуру случайного доступа, ей уже выделен идентификатор C-RNTI. Поэтому МС принимает канал PDCCH (Physical Downlink Control Channel) и ищет выделение ресурсов, адресованное ее C-RNTI. После этого МС принимает сообщение ‘RRC Connection Setup’, которое передается по сигнальному соединению SRB0, логическому каналу CCCH (Common Control Channel) и физическому каналу PDSCH (Physical Downlink Shared Channel). В этом сообщении передается конфигурация для сигнального соединения SRB1. После этого соединение SRB1 может использоваться для передачи управляющей информации. Напомним, что соединение SRB1 на логическом уровне использует канал DCCH (Dedicated Control Channel). В сообщении ‘RRC Connection Setup’ не передается конфигурация соединения SRB2, так как это соединение настраивается после активации защиты передачи информации. Соединение SRB2 имеет более низний приоритет (3), чем соединение SRB1 (1). При этом, оба соединения используют режим передачи с подтверждениями на уровне RLC. Соединение SRB1 может быть сконфигурено либо по умолчанию, либо с некоторыми специальными настройками. Конфигурацию по умолчанию можно найти в документе 3GPP TS 36.331.
МС в сообщение ‘RRC Connection Setup Complete’ также включает начальное сообщение NAS (Non-Access Stratum). В качестве таких сообщений могут выступать следующие: Attach, Detach, Tracking Area Update, Service Request и Extended Service Request. В случае процедуры подключения к сети МС включает сообщение ‘Attach Request’ в сообщение ‘RRC Connection Setup Complete’. БС достает это сообщение и передает его на MME.
Поле ‘ESM Message Container’ используется для того, чтобы передать сообщение ‘PDN Connectivity Request’, которое является еще одним NAS сообщением. Содержание этого сообщения приводится в следующей таблице.
Тело сообщения начинается с поля ‘Request Type’, в которое может принимать одно из следующих двух значений: ‘Initial Request’ или ‘Handover’. Значение ‘Handover’ используется в тех случаях, когда МС переходит в сети LTE из других сетей. В следующем поле сообщения ‘PDN Type’ передается информация о том, какие версии протокола IP поддерживаются МС (возможные значения: IPv4, IPv6, IPv4v6).
После отправки сообщения ‘Attach Request’ МС запускает таймер T3410. Значение этого таймера составляет 15 секунд. Если таймер истечет раньше, чем МС получит ответ от MME, то текущая попытка регистрации считается неуспешной и счетчик количества попыток увеличивается на 1. После этого, если счетчик попыток меньше, чем 5, то МС запускает таймер T3411. Значение таймера T3411 составляет 10 секунд. Как только этот таймер истечет, МС повторяет посылку сообщения ‘Attach Request’. Если же значение счетчика попыток больше 5, то МС запускает таймер T3402 и сбрасывает значение GUTI, TAI и список PLMN. Значение по умолчанию таймера T3402 составляет 12 минут. Это значение может быть изменено с помощью сообщений ‘Attach Accept’ или ‘Tracking Area Update Accept’. Значение, передаваемое в этих сообщениях актуально только для тех областей слежения (Tracking Area), которые указаны в сообщении. Процедура регистрации начинается снова, как только таймер T3402 истечет.
Если МС передавала поле ‘ESM Information Transfer Flag’ в сообщении ‘PDN Connectivity Request’, то MME запускает процедуру по получению значения APN (Access Point Name) и ее настроек. Эта процедура начинается с сообщения ‘ESM Information Request’, отправляемое с MME. Данное сообщение состоит только из заголовка. В ответ МС отправляет сообщение ‘ESM Information Response’, в котором передается APN и ее параметры (могут передаваться логин и пароль). Если МС не включила поле ‘ESM Information Transfer Flag’ в сообщении ‘PDN Connectivity Request’, то будет использована APN по умолчанию.
После отправки сообщения ‘Attach Accept’ MME запускает таймер T3450. Значение этого таймера равно 6 секундам. Если до истечения этого таймера MME не получил ответ от МС, то посылка сообщения ‘Attach Accept’ повторяется. Всего посылка этого сообщения может быть повторена 4 раза. Ниже в таблице приводится содержание сообщения ‘Attach Accept’.
Поле ‘ESM Message Container’ используется для того, чтобы передать сообщение ‘Activate Default EPS Bearer Context Request’. В этом сообщении передаются параметры соединения по умолчанию (такие, как качество обслуживания, APN и т.д.). БС достает сообщение ‘Attach Accept’ из сообщения ‘Initial Context Setup Request’ и передает его МС в сообщении ‘RRC Connection Reconfiguration’. В ответ МС отправляет сообщение ‘RRC Connection Reconfiguration Complete’. Так как МС в это сообщение не может включить сообщение ‘Attach Complete’, она передает его отдельно. БС завершает процедуру S1-AP Initial Context Setup отправкой сообщения ‘Initial Context Setup Response’ на MME.
В сообщении ‘Attach Complete’ также передается сообщение ‘Activate Default EPS Bearer Context Accept’. Как только БС получает оба сообщения ‘Initial Context Response’ и ‘Attach Accept’, она отправляет сообщение ‘Modify Bearer Request’ на S-GW. В этом сообщение передается адрес для нисходящих данных и идентификатор туннеля (GTP TEID). Эти параметры берутся из сообщения ‘S1-AP Initial Context Setup Response’. В свою очередь, S-GW отправляет сообщение ‘Modify Bearer Response’ на MME, которое носит цель подтверждения. На этом процедура заканчивается.
LTE AND BEYOND
LTE, 4G, EPC, MME, PGW, SGW, Interfaces and beyond tech-blog by Bart Barton
If you liked it, or content was helpful to you please add «+1» to article you used or share it on facebook or so.
Make it easier to find for others who could need those information, allow them find these articles on the spot. But.. it’s your call.
Recommendations until now
Jan 28, 2012
LTE attach procedure
Always it’s good to start with a high level abstract picture, but not today.
Being honest, today I’m a little bit lazy and just don’t want to draw network architecture myself. You can easily find that on Google image search engine.
Information below are part of 3GPP TS 23.401, I just copied them. Below is everything you need to know about Network Attach procedure in LTE with many references.
UE needs to register with the network to receive services that require registration. This registration is called Network Attachment. The always on IP connectivity for UE is enabled by establishing a default EPS bearer during Network Attachment procedure. Predefined PCC rules most common set in PGW will be applied for default bearer. Attach procedure may trigger one or multiple Dedicated Bearer Establishment procedures to establish dedicated EPS bearer for that UE.
During the Initial Attach procedure the Mobile Equipment Identity is obtained from the UE. The MME operator may check the Mobile Equipment Identity with EIR. At least in roaming situations, the MME should pass the ME Identity to the HSS, and, if a PGW outside of the VPLMN (Visited PLMN), should pass the ME Identity to the PGW.
The E-UTRAN Initial Attach procedure is used for Emergency Attach by UEs that need to perform emergency service but cannot gain normal services from the network. These UEs are in limited service state (more about this in 3GPP TS 23.122). Also UEs that had attached for normal services and do not have emergency bearers established and are camped on a cell in limited service state shall initiate the Attach procedures indicating that the attach is to receive emergency services. UEs that camp normally on a cell, i.e. UEs that are not in limited service state, should initiate normal initial attach when they are not already attached and shall initiate the UE Requested PDN Connectivity procedure to receive emergency EPS bearer services.
Maybe you will find Combined Attach information interesting as well.
Прохождение вызовов в сети 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 не оповещает вызываемого пользователя о поступившем вызове и не генерирует медиа поток до резервирования ресурсов на обеих сторонах.
