 |
Установление соединения с сетью
|
|
|
|
Процедура RRC connection establishment относится к протоколу RRC (рис. 4.2), описана в [11].
Рис. 4.2. Процедура RRC connection establishment
Процедура происходит при переходе UE в состояние CONNECTED из состояний Detached и IDLE. В результате процедуры устанавливается соединение по SRB1 (Signal Radio Bearer 1).
Согласно [11] передача сигнализации для каждого UE идет по организуемым SRB. SRB1 и SRB2 используют постоянно:
- SRB2 для сообщений NAS, DCCH на логическом уровне,
- SRB1 для остальных сигнальных сообщений логического уровня DCCH, в том числе и NAS до установки SRB2.
Существует также SRB0 для передачи сообщений канала СССН в начале процедуры RRC connection establishment до установления SRB1.
Сообщение RRC Connection Request содержит:
- идентификатор UE (S-TMSI при пейджинге и при повторных запросах услуг),
- причину запроса соединения – срочный вызов (emergency), высокоприоритетный доступ (High Priority Access), доступ, инициируемый сетью (Mobile Terminating), передача данных, инициируемая UE (Mobile Originating), сигнализация, инициируемая UE (Mobile Originating).
Сообщение RRC Connection Setup устанавливает SRB1.
Процедура Attach
С процедуры Attach (подключения) начинается каждый сеанс связи. При этом происходит регистрация UE в сети, подсоединения UE к EPC для реализации услуг передачи пакетного трафика. Ядро сети организует сквозное соединение по протоколу IP: сквозной канал по умолчанию (default EPC bearer). После выполнения процедуры Attach могут быть добавлены один или несколько выделенных каналов (процедура Dedicated Bearer Establishment). При выполнении процедуры Attach происходит активизация или выделение абоненту IP-адреса.
Спецификациями [20] предусмотрены 3 варианта запуска процедуры:
- когда UE находится в режиме с коммутацией пакетов,
- когда UE находится в состоянии с коммутацией каналов/пакетов,
|
|
|
- при организации срочных вызовов (emergency). При этом возможна ситуация, когда ММЕ (сеть) не поддерживает срочных вызовов. Существуют особенности процедуры Attach при межсистемных хэндоверах.
Алгоритм процедуры приведен на рис.4.3 [20]. Первое сообщение Attach Request (рис.4.3, п.1), которое UE посылает на eNB, содержит большое число параметров, в том числе:
- идентификатор абонента (IMSI или GUTI = GUMMEI + M-TMSI),
- идентификатор последней визитной зоны TAI (Tracking Area Identity),
- UE Core Network Capability (возможность работы в разных сетях, поддержка IMS и проч.),
- тип процедуры (EPS Attach, Combined EPS/IMSI Attach, Emergency Attach),
- параметры, необходимые для выполнения процедур безопасности, если они были установлены ранее. При этом UE может защитить целостность передаваемого сообщения Attach Request. При положительном результате проверки целостности пришедшего сообщения Attach Request ММЕ использует для выполнения защиты информации хранящиеся в базе данных абонента вектора аутентификации [1, гл.6].
Attach Request также содержит указание требуемого типа пакетной сети (поддержка протоколов IPv4, IPv6 или IPv4/IPv6) и соответственный вариант IP-адреса. UE может установить прямой обмен параметрами с PDN GW Рис. 4.3. Процедура Attach
посредством РСО (Protocol Configuration Options), в том числе в зашифрованном виде.[6] При этом UE передает на PDN GW имя точки доступа APN и совокупную максимальную скорость передачи в точке доступа APN-AMBR (Aggregated maximum Bit Rate).[7]
В п.2 eNB извлекает из Attach Request, переданного UE, идентификатор ММЕ, который обслуживал UE в предыдущем сеансе связи. Если eNB не имеет выхода на этот ММЕ, то он выбирает новый ММЕ, который будет обслуживать абонента. В сообщение Attach Request,направленном обслуживающему ММЕ, eNB дополнительно включает глобальный идентификатор зоны TAI и глобальный идентификатор соты ECGI (E-UTRAN Cell Global Identifier), откуда поступил запрос. TAI (Tracking Area Identity) состоит из кода страны, кода оператора и кода зоны TAC (Tracking Area Code – 16 бит). В ECGI в макро и микросетях идентификатор eNB определяют 20 бит, а в фемтосетях 28 бит являются кодом домашней базовой станции НeNB. [23]. Таким образом, уже на этапе подключения абонента к сети его можно локализовать с точностью до соты.
|
|
|
П.3. Если произошла смена ММЕ после последнего сеанса связи, то новый ММЕ (new MME) пересылает Attach Request Message на старый ММЕ (old MME) для получения системного номера (IMSI) абонента. Старый ММЕ проверяет целостность полученного сообщения Attach Request и отвечает сообщением Identification Response. Оно содержит IMSI абонента и его базу данных (MM Context), сохраненную с предыдущего сеанса связи. Если база абонента удалена или целостность сообщения Attach Request нарушена, то старый ММЕ сообщает об ошибке и полностью производится процедура безопасности по протоколу ММ (пп. 4 – 6).
П.4. Если идентификатор абонента IMSI не удалось определить, ММЕ посылает запрос абоненту Identity Request. Ответ Identity Response содержит IMSI.
П.5а – процедуры взаимной аутентификации и установления режима шифрации выполняют обязательно, если параметры безопасности определяют заново. Если можно использовать результаты предыдущего сеанса связи, то необходимость выполнения п.5а определяет оператор.
В п.5b осуществляют проверку мобильного терминала (IMEI – International Mobile Equipment Identity).
П.6 выполняют в том случае, когда UE просит организовать в РСО шифрацию при передаче параметров подключения к IP-сети в PDN GW (см. п.1).
П.7. Если при завершении предыдущего сеанса связи в контексте абонентских параметров, сохраненных в старом ММЕ, не были удалены параметры организованных сквозных каналов (процедура завершения сеанса связи Detach не была выполнена полностью), новый ММЕ удаляет эти каналы, посылая команду Delete Session Request в S-GW и PDN GW. PDN GW сообщает PCRF о завершении предыдущего сеанса связи и о высвобождении выделенного канального ресурса – блоки (Е) – (А). Это же относится и к блокам (F) – (B) п.10, когда произошла замена ММЕ.
П.8. Если произошла смена ММЕ или база данных абонента в ММЕ организуется заново, то новый ММЕ направляет запрос Update Location Request в HSS. HSS фиксирует идентификатор обслуживающего абонента ММЕ, даёт команду стереть базу данных абонента в старом ММЕ (Cancel Location, п.9) и посылает сообщение Update Location Ack) в новый ММЕ (п.11).
|
|
|
В команде Update Location Ack передают IMSI абонента и Subscription Data – параметры услуг (PDN Subscription Context), которые могут быть предоставлены абоненту. В Subscription Data записаны параметры одной или нескольких услуг (РDN) для APN. Каждая услуга в PDN Subscription Context содержит требования к качественным характеристикам: EPS Subscription QoS Profile. Новый ММЕ проверяет возможность обслуживания абонента в новой зоне. Если абонент не имеет прав на обслуживание в данной зоне, тогда ММЕ прерывает процедуру Attach, о чем UE получает соответствующее уведомление.
П.12. Команда Create Session Request содержит все данные, которые необходимы для организации сквозного канала по умолчанию. В большинстве случаев UE передаёт имя точки доступа APN, что определяет адрес PDN GW. Если APN неизвестен, то ММЕ выделяет его по умолчанию.
ММЕ выбирает S-GW и назначает идентификатор сквозного канала по умолчанию. В сообщении Create Session Request передают IMSI, MSISDN[8], IMEI, адрес PDN GW, параметры QoS организуемого канала, IP-адрес абонента, тип протокола на интерфейсе S5/S8, ECGI, временной пояс, где находится абонент[9], APN-AMBR и ряд параметров, характеризующих сеть и особенности процедуры. Create Session Request также содержит идентификатор туннеля TEID на сигнальном интерфейсе S-11 в направлении S-GW → ММЕ (рис. 1.1).
П.13. S-GW создаёт новую запись в таблице сквозных каналов и пересылает полученные от ММЕ параметры, в том числе информацию о локализации абонента, на PDN GW по адресу, указанному в команде (п.12). Сообщение (п.13) Create Session Request также сдержит конечные точки TEID туннелей в плоскости трафика и сигнальной плоскости на интерфейсе S5/S8 в направлении PDN GW → S-GW. Теперь S-GW готов буферизировать пакеты, следующие вниз от PDN GW.
П.14. Получив сообщение Create Session Request, PDN GW осуществляет процедуру запуска сеанса связи IP-CAN (Connectivity Access Network) Session Establishment или его модификации (Modiification) в случае хэндовера. Всю информацию об абоненте и организуемой услуге: IMSI, IP-адрес абонента, APN, сеть обслуживания, данные о локализации и др. PDN GW направляет в PCRF, который может принять, а может и изменить параметры QoS организуемого сквозного канала. При назначении тарифа для оплаты услуг используют данные о локализации абонента и часовом поясе, где он находится.
|
|
|
П.15. PDN GW создаёт в базе данных сквозных каналов запись о новом канале и присваивает ему идентификатор для тарификации трафика (Charging Id). Теперь и в PDN GW, и в S-GW открыты базы данных абонента. Организуется сквозной канал для пакетного обмена между PDN GW и S-GW. Сообщение Create Session Response содержит все характеристики сквозного канала, в том числе варианты используемого протокола IP (IPv4 или IPv6). Активизируется PDN адрес абонента. Абонент может иметь статический или динамический адрес в домашней сети или получить динамический адрес в визитной сети. Выделение динамического адреса осуществляет DHCP (Domain Host Configuration Protocol). Для создания туннелей вверх на интерфейсе S5/S8 в Create Session Response передают TEID туннельных соединений в пользовательской и сигнальной плоскостях.
Теперь пришедшие ранее пакеты данных из PDN GW могут быть переданы в буфер S-GW.
П.16. Получив сообщение Create Session Response, S-GW заносит характеристики сквозного канала в базу данных и передаёт необходимые параметры в ММЕ для организации сквозного канала на интерфейсе S1 м радиоинтерфейсе.
П.17. ММЕ передает на eNB 2 сигнальных сообщения. Внутреннее сообщение Attach Accept содержит параметры организованного сквозного канала, номер сигнального сообщения NAS между UE и ММЕ и новый GUTI, если абонента стал обслуживать новый ММЕ. Сообщение Attach Accept в п. 18 будет далее переслано UE. В п.17 Attach Accept размещено в команде Initial Context Setup Request, где дополнительно для eNB передают параметры безопасности, а также сквозного канала на интерфейсе S1:, адрес S-GW и TEID туннеля вверх на S1.
П.18. eNB направляет UE сообщение RRC Connection Reconfiguration, содержащее Attach Accept и идентификатор сквозного канала на радиоинтерфейсе EPS Radio Bearer Identity. UE получает имя точки доступа APN и активизированный IP-адрес. В ответном сообщении RRC Connection Reconfiguration Complete (п.19) UE подтверждает получение необходимой информации.
П.20. Сообщение Initial Context Setup Response содержит адрес eNB и TEID сквозного канала вниз на интерфейсе S1.
П.21. В сообщении Direct Transfer UE передаёт команду Attach Complete (идентификатор сквозного канала, номер сообщения NAS), адресованную ММЕ. eNB ретранслирует Attach Complete в ММЕ (п.22). После этого UE может начать передачу пакетов вверх.
П.23. Сообщение Modify Bearer Request содержит идентификатор сквозного канала, адрес eNB, eNB TEID, что необходимо для организации на интерфейсе S1 туннеля вниз.
При межсистемном хэндовере в Modify Bearer Request передают индикатор хэндовера и далее выполняют команды 23а и 23b (блок D). S-GW информирует PDN GW о завершении организации сквозного канала на участке eNB ‒ S-GW. Теперь пользовательские пакеты можно направлять на eNB по интерфейсу S1.
|
|
|
П.24. Команда Modify Bearer Response является подтверждением получения команды Modify Bearer Request. Теперь модно начать прямую передачу пользовательских пакетов вниз.
Сообщения пп.25 и 26 передают только в том случае, если ММЕ назначил для сквозного канала PDN GW отличный от того, что прописан в базе данных абонента в HSS. ММЕ информирует HSS о выбранном PDN GW и APN. HSS вносит их в базу данных абонента и отправляет в ММЕ подтверждение.
Процедура локализации
Процедура локализации TAU (Tracking Area Update) происходит, когда UE, находящийся в состоянии IDLE, перемещается при движении абонента в соту, расположенную в зоне слежения, которая не указана в списке зон регистрации абонента. Напомним, что ММЕ может регистрировать абонента в одной зоне слежения или в нескольких зонах. В этом случае UE при последней локализации получает от ММЕ список зон, по которым будут передавать сигналы пейджинга. В сети также предусмотрена периодическая локализация, когда UE через определенное время запускает процедуру TAU, чтобы подтвердить свою доступность.
Когда UE зарегистрирован в сети и пребывает в состоянии IDLE, в ММЕ, S-GW, PDN GW открыты базы данных абонента, сохраняются сигнальные туннели на S1, S5/S8 и туннели для сквозных каналов на S5/S8. Процедура TAU может происходить без замены ММЕ, со сменой ММЕ и со сменой S-GW. Алгоритм процедуры с заменой ММЕ приведен на рис. 4.4 [20].
Процедуру запускает UE (п.1). После установления соединения с сетью следует сообщение Tracking Area Update (TAU) Request (п.2). Оно содержит идентификаторы и параметры обслуживающей абонента сети, GUTI, идентификатор последней зоны пребывания UE, параметры безопасности, порядковый номер передаваемого сообщения NAS. Эта команда должна быть защищена кодом целостности сообщения МАС (Message Authentication Code). [10]
П.3. Из полученного сообщения eNB извлекает старый GUMMEI и определяет сеть, в которой зарегистрирован абонент. eNB направляет запрос на локализацию в новый ММЕ, дополняя его параметром TAI+ECGI, что позволяет локализовать абонента с точностью до соты.
П.4. ММЕ определяет старый ММЕ (old MME) и отправляет ему запрос Context Request для получения базы данных абонента. Это сообщение содержит TAU Request, чтобы старый ММЕ мог проверить и подтвердить его целостность. Если TAU Request содержал параметры SGSN, то запрос направляют в SGSN.
П.5. Старый ММЕ проверяет целостность сообщения TAU Request и если она подтверждена, то в сообщении Context Response пересылает базу данных абонента и UE: IMSI, MSISDN, параметры безопасности, контекст сквозных каналов, адрес сигнальный TEID S-GW и т.д. Если целостность TAU Request нарушена или в старом ММЕ нет базы данных абонента, то Context Response содержит информацию об ошибке. В этом случае обязателен к выполнению п.6. ММЕ запускает в полном объеме процедуры безопасности: аутентификации и генерации ключей шифрации и целостности [1, гл.6]. При получении параметров безопасности в Context Response объем выполнения п.6 определяет оператор. ММЕ отправляет в старый ММЕ подтверждение в получении базы данных абонента (Context Acknowledge, п.7).
П.9. Если произошла смена ММЕ, новый ММЕ создает базу данных абонента, устанавливая контекст его сквозных каналов, полученный из старого ММЕ. При этом он проверяет возможность поддержки ранее организованных каналов и деактивирует те соединения, которые он поддерживать не может. Далее он организует сигнальное соединение на интерфейсе S11. Сообщение Modify Bearer Request содержит тип сети, адрес ММЕ и TEID. Опционально ММЕ может активизировать ISR. Из полученного контекста сквозных каналов абонента ММЕ определяет адрес S-GW и при смене сети передает в S-GW идентификатор новой сети, а также изменения часового пояса обслуживания абонента и его местоположения.
Рис. 4.4. Процедура TAU с заменой ММЕ
ПП. 10. 11, 12 (блок А) выполняют в случае, когда произошла смена сети обслуживания, часового пояса или локализации абонента, что связано с изменением тарифов услуг. S-GW передаёт необходимую информацию в PDN GW, а PDN GW запускает процедуру IP-CAN Session Modification Procedure [20].
П.13. S-GW обновляет базу данных абонента и направляет в ММЕ сообщение Modify Bearer Response, содержащее адрес S-GW и TEID для передачи трафика вверх.
П.14. Новый ММЕ проверяет наличие необходимых данных для UE и, если произошла смена ММЕ, информирует об этом HSS (Update Location Request), сообщая свой адрес и возможности в обслуживании абонента. HSS посылает в старый ММЕ команду Cancel Location (п.15). Старый ММЕ может сразу удалить базу данных абонента или спустя некоторое время, запустив соответствующий таймер. В HSS он отсылает подтверждение Cancel Location Ack.
ПП.17 и 18 выполняют в том случае, когда UE подсоединен через Iu интерфейс с контроллером сети GERAN/UTRAN.
П.19. HSS подтверждает получение сообщения от нового ММЕ (Update Location Ack) и при необходимости передаёт в новый ММЕ дополнительные данные об абоненте. ММЕ завершает формирование базы данных абонента. В сообщении Tracking Area Update Accept (п.20) абонент получает GUTI, список зон регистрации (TAI-list), статус сквозных каналов (часть прежних каналов может быть удалена). Если GUTI изменился, UE подтверждает получение сообщения Tracking Area Update Accept (п.21).
4.5. Перевод абонентской станции в состояние Idle
При переводе UE из состояния CONNECTED в состояние IDLE происходит разрыв сигнального соединения UE – ММЕ и разрушение участков сквозных каналов трафика на радиоинтерфейсе и интерфейсе S1. eNB удаляет базу данных, относящуюся к UE. В спецификациях [20] ‒ это S1 Release Procedure (рис. 4.5).
Рис. 4.5. Процедура освобождения интерфейса S1
Обычно эту процедуру запускает eNB (п.1), например, при срабатывании таймера неактивности абонента или разрыва с UE сигнального соединения, но её может инициировать и ММЕ. Получив от eNB сообщение S1-AP: S1 UE Context Release Request, ММЕ направляет в S-GW команду Release Access Bearer Request (п.2).
S-GW убирает из базы данных UE всё, что касается eNB (адрес и TEID по S1 вниз) и отвечает ММЕ сообщением Release Access Bearer Response (п.3). Все остальные данные контекста UE S-GW сохраняет. Это параметры организованных ранее сквозных каналов данного абонента, в частности, туннелей на интерфейсе S5/S8 и их конфигурацию на S1-U. Сохраняются и TEID туннельных соединений вверх на S1-U и S11. Поэтому при поступлении пакетов входящего трафика, когда UE находится в состоянии IDLE, S-GW буферизирует эти пакеты и запускает процедуру Service Request (рис. 4.6).
П.4. ММЕ освобождает интерфейс S1, отправляя eNBкоманду S1-AP: S1 UE Context Release Command. Если eNB ещё не разорвал соединения с UE по протоколу RRC, он передает UE сообщение RRC Connection Release (п.5), требуя подтверждения. В сообщении S1-AP: S1 UE Context Release Complete (п.6)eNB информирует ММЕ об освобождении интерфейса S1 от сквозных каналов абонента. Получив от UE подтверждение получения сообщения (п.5), eNB удаляет базу данных UE.
MME из контекста UE стирает всю информацию, относящуюся к eNB (адрес, идентификаторы соединений), но остальные данные сохраняет для последующей процедуры Service Request.
4.6. Процедура Service Request
Service Request – процедура запроса услуги передачи данных по ранее организованному сквозному каналу. На интерфейсе S5/S8 существует туннель для пакетов трафика, а в PDN GW, S-GW и ММЕ‒ параметры сквозного канала занесенные в соответствующие базы данных. Процедуру может инициировать как абонент, так и сеть (входящий вызов). Как правило, при этой процедуре станция переходит из состояния IDLE в состояние CONNECTED. Алгоритм процедуры Service Request при запуске со стороны абонента представлен на рис. 4.6 [20].
UE посылает сообщение NAS:Service Request (п.1), которое eNB доставляет в ММЕ, дополняя его идентификатором соты (TAI+ECGI) и временным идентификатором абонента S-TMSI. (п.2). ММЕ может запустить процедуры аутентификации и генерации ключей безопасности или использовать данные, полученные ранее (п.3) [1, гл.6].
ММЕ направляет в eNB сообщение S1-AP: Initial Context Setup Request (п.4). Оно содержит адрес S-GW, TEID туннеля вверх на интерфейсе S1-U, параметры QoS организуемого сквозного канала, параметры безопасности, идентификатор сигнального соединения, список ограничений при хэндовере[11]. eNB заполняет базу данных обслуживаемого абонента и организует канал трафика на радиоинтерфейсе, включая шифрацию пользовательской информации (п.5). Теперь UE может начать передачу пользовательских пакетов вверх Uplink Data (п.6).
Рис.4.6. Процедура Service Request, запускаемая UE
П.7. eNB в сообщении S1-AP: Initial Context Setup Complete, передает ММЕ свой адрес, список установленных (принятых) и удаленных сквозных каналов абонента, TEID туннеля вниз на интерфейсе S1-U.
П.8. ММЕ отсылает S-GW сообщение Modify Bearer Request (адрес eNB, TEID туннеля вниз на интерфейсе S1-U, тип сети радиодоступа RAT). Теперь завершена организация туннельного соединения на интерфейсе S1-U. Если произошли изменения сети обслуживания абонента или часового пояса, то эту информацию ММЕ также включает в данную команду.
ПП.9 – 11 (блок А) выполняют только при смене сети обслуживания абонента или часового пояса. Эти изменения должны быть учтены PCRF, в частности, в установлении тарифов.
Подтверждение S-GW о завершении организации сквозного канала (п.12 Modify Bearer Response) заканчивает процедуру.
Алгоритм процедуры Service Request при входящих вызовах (поступлении пакетов трафика со стороны сети) показан на рис. 4.7 [20].
Он представляет собой процедуру Service Request, рассмотренную ранее (в п.5 использован алгоритм на рис. 4.6), дополненную командами пейджинга абонентского терминала.
Рис.4.7. Процедура Service Request, запускаемая сетью
Пришедшие пакеты трафика PDN GW направляет в S-GW по существующему туннелю на интерфейсе S5/S8. S-GW их буферизирует. Передавать дальше он их не может, так как сквозной канал на участке UE ‒ eNB ‒ S-GW отсутствует. S-GW определяет, какой ММЕ или SGSN ведет базу данных абонента и посылает туда уведомление (п.2а Downlink Data Notification). ММЕ или SGSN подтверждают получение уведомления (п.2b Downlink Data Notification Ack), формируют сообщение пейджинга (3а,b), которое через eNB или RNC/BSC доставляют UE (4a,b).
Если UE находится в состоянии IDLE, то алгоритм (рис.4.6) выполняют полностью, начиная с первого сообщения NAS:Service Request. В том случае, когда между UE и ММЕ существует сигнальное соединение (например, абонент получает трафик по другому сквозному каналу), но туннель на S1-U для данной услуги отсутствует, то алгоритм (рис. 4.6) запускают с п.4: ММЕ посылает команду S1-AP: Initial Context Setup Request организовать сквозной канал на радиоинтерфейсе.
ПП.6а и 6b выполняют, когда активизирован ISR. Если S-GW получил информацию от ММЕ об отправке сообщения пейджинга, он посылает SGSN команду Stop Paging. Наоборот, при отправке сообщения пейджинга из SGSN команду Stop Paging получает ММЕ.
Процедура Detach
Процедуру Detach – отключение абонента от сети, может запускать как абонент, так и сеть, например, когда истекает время нахождения UE в состоянии IDLE. В этом случае процедуру инициирует ММЕ.
На рис. 4.8 приведен протокол процедуры Detach, запускаемой UE [20].
UE посылает сообщение Detach Request, содержащее GUTI и Switch off (п.1). eNB, пересылая это сообщение в ММЕ, добавляет к нему идентификатор соты, где находится абонент, TAI+ECGI.
Посылая сообщение Delete Session Request в S-GW (п.2), MME запускает процедуру деактивации сквозных каналов. S-GW стирает базу данных абонента и отправляет команду Delete Session Request в PDN GW деактивировать сквозные каналы на интерфейсе S5/S8 (п.6). PDN GW стирает базу данных абонента и запускает процедуру освобождения канального ресурса (завершения сеанса связи) IP-CAN Session Termination Procedure (п.8) [23]. О выполнении команд S-GW информирует ММЕ (п.3), а PDN GW ‒ S-GW (п.7).
Рис.4.8. Процедура Detach
Если был активирован ISR, т.е. UE был параллельно подключен к сетям E-UTRAN и GERAN/UTRAN, ММЕ командой Detach Notification (п.4) деактивирует базу данных абонента в SGSN, о чем тот информирует S-GW (п.5, Delete Session Request). В этом варианте процедуры команду (п.6) S-GW отсылает только после получения сообщения (п.5).
Сообщения (пп.9, 10, 11), подтверждающие выполнение соответствующих команд, опциональны. Командой Signaling Connection Release (п.12) ММЕ освобождает сигнальное соединение на интерфейсе S1. Происходит стирание данных UE в eNB. ММЕ сохраняет базу данных абонента в заблокированном состоянии.
|
|
|
