 |
Процедура межсистемного хэндовера из E-UTRAN в UTRAN
|
|
|
|
Межсистемные хэндоверы UE возможны между сетями E-UTRAN (LTE)–UTRAN (UMTS), E-UTRAN–GERAN и E-UTRAN–CDMA2000. В этом и следующем параграфах будут рассмотрены хэндоверы E-UTRAN–UTRAN.
Процедура хэндовера из E-UTRAN в UTRAN состоит из двух фаз: подготовки хэндовера и выполнения хэндовера. До начала процедуры трафик идет через исходный eNB (Source eNB), исходный S-GW и PDN GW. Алгоритм подготовки хэндовера приведен на рис. 4.15 [20].
Рис.4.15. Подготовка хэндовера из E-UTRAN в UTRAN
П.2. Процедуру запускает исходный eNB (п.1). eNB посылает ММЕ сообщение Handover Required, содержащее Cause[12], идентификатор целевого (target) RNC и контейнер данных для того, чтобы выделить необходимые ресурсы для обслуживания абонента в RNC, SGSN и S-GW. Далее в п.7 SGSN идентифицирует сквозные каналы, которые надо будет организовать при переключении на сеть UMTS (UTRAN).
П.3. Из полученного сообщения ММЕ определяет, что eNB запрашивает межсетевой хэндовер. ММЕ определяет целевой (target) SGSN, который будет обслуживать абонента в сети UMTS. Если активизирован ISR, то приоритетным будет SGSN, где зарегистрирован абонент. ММЕ отправляет SGSN сообщение Forward Relocation Request о выделении ресурсов для обслуживания абонента, включающее IMSI, идентификатор RNC, Cause, базу данных (контекст) по протоколу ММ, идентификатор текущей сети обслуживания, адрес ММЕ и TEID интерфейса для сигнализации, контейнер данных абонента, часовой пояс обслуживания абонента. В сообщении приведен контекст всех сквозных каналов, обслуживающих абонента, для каждого соединения указана точка доступа (APN), а также адрес исходного S-GW и его TEID на сигнальном туннеле вверх.
Получив сообщение Forward Relocation Request, целевой SGSN устанавливает PDP-контекст абонента и заносит в него параметры переключаемых сквозных каналов. База данных по протоколу ММ обеспечивает выполнение процедур безопасности при обслуживании абонента в сети UMTS. SGSN определяет максимальную пропускную способность потоков данных абонента через точки доступа.
|
|
|
SGSN устанавливает контекст сквозных каналов для UE.
П.4. В случае смены сети обслуживания SGSN заменяет исходный S-GW на целевой (target) S-GW и направляет ему сообщение Create Session Request. Оно содержит IMSI, адрес SGSN и TEID для сигнального соединения, адреса PDN GW для пользовательских каналов и сигнальных соединений, PDN GW TEID туннелей вверх в пользовательской и сигнальной плоскостях, тип соединения на S5/S8 (IPv4 или IPv6). Требуемый тип протокола устанавливает S-GW.
Целевой S-GW выделяет ресурс для обслуживания абонента и отвечает сообщением Create Session Response (адреса S-GW в пользовательской и сигнальной плоскостях, TEID туннелей вверх в пользовательской и сигнальной плоскостях) – п.4а.
П.5. SGSN посылает запрос Relocation Request на целевой RNC для выделения канального ресурса и организации туннелей. Запрос содержит идентификатор UE, Cause, индикатор ядра сети, базу данных для выполнения процедур безопасности, список сквозных каналов с их параметрами, контейнер данных UE, информацию об ограничениях доступа абонента к ресурсам сети при хэндоверах. В запрос также включают адрес S-GW в пользовательской плоскости в случае прямого туннеля RNC ↔ S-GW или адрес SGSN при непрямом туннеле и соответствующие TEID для туннелей вверх. RNC выделяет ресурсы для организации запрошенных сквозных каналов.
П.5а. В обратном сообщении Relocation Request Acknowledge RNC отправляет контейнер для eNB, список установленных сквозных каналов и, если есть таковые, список каналов, которые не установлены и чей контекст будет деактивирован. Теперь RNC готов принимать пакеты данных абонента в направлении вниз по организованным сквозным каналам.
П.6 выполняют в случае замены S-GW и создания обходного пути (Indirect Forwarding) для трафика вниз в процессе хэндовера. Если в UTRAN существует прямой туннель GW↔RNC (см.комментарий к рис.1.6), то в сообщении Create Indirect Data Forwarding Tunnel Request целевой S-GW получает адрес и TEID RNC. При использовании непрямого туннеля S-GW получает адрес и TEID SGSN. В обратном сообщении Create Indirect Data Forwarding Tunnel Response S-GW передает свой адрес и TEID (п.6а).
|
|
|
П.7. SGSN отправляет ММЕ ответ Forward Relocation Response (Cause, адрес SGSN и TEID для сигнализации, контейнер для UE, индикатор замены S-GW, информация об организации сквозных каналов в сети UTRAN и параметры для организации промежуточных туннелей при передаче трафика вниз в процессе хэндовера).
Если не было замены S-GW или была замена, но существует прямое физическое соединение между исходным eNB и целевым RNC (Direct Forwarding), то сообщают адрес и TEID RNC для каналов трафика.
Если нет физического соединения между исходным eNB и целевым RNC (Indirect Forwarding) и произошла замена исходного S-GW на целевой, то сообщают адрес и TEID целевого S-GW.
Если замены S-GW не было, но при передаче вниз будут использованы Indirect Forwarding и непрямой туннель S-GW → SGSN, то сообщают адрес и TEID SGSN.
П.8 выполняют при организации Indirect Forwarding. ММЕ направляет в S-GW, используемый при Indirect Forwarding, сообщение Create Indirect Data Forwarding Tunnel Request, содержащее идентификаторы сквозных каналов, адрес и TEID, полученные ММЕ в п.7. Обычно этим S-GW является исходный S-GW, но может быть и другой обслуживающий шлюз. В ответном сообщении Create Indirect Data Forwarding Tunnel Response (п.8а) S-GW сообщает свой адрес и TEID для организации временного туннеля.
Алгоритм следующей фазы выполнения хэндовера показан на рис. 4.16.
П.1. ММЕ завершает подготовку к хэндоверу, посылая eNB Handover Command, содержащую контейнер для eNB, список сквозных каналов, которые следует деактивировать, и каналов, которые надо организовать для временной передачи трафика вниз (Bearers Subject to Data forwarding list). Для организации этих каналов eNB получает адреса и TEID, которые были пересланы ММЕ в пп. 7 при Direct Forwarding или 8а при Indirect Forwarding подготовительной фазы (рис. 4.16). В результате будет обеспечен либо прямой путь передачи данных eNB → RNC, либо обходной через исходный S-GW в зависимости от конфигурации сети.
П.2. eNB посылает UE команду выполнить хэндовер. В этой команде UE передают контейнер, содержащий необходимые для хэндовера параметры, которые RNC загрузил в контейнер в подготовительной фазе. Приняв команду, UE останавливает передачу трафика вверх, идентифицирует сквозные каналы в соответствии с протоколом доступа с коммутацией пакетов в UTRAN и выполняет процедуру хэндовера согласно [25] (п.4). По завершении хэндовера UE может начать передавать трафик вверх.
|
|
|
Что касается передачи трафика вниз, то при смене S-GW он по-прежнему идет по маршруту PDN GW→исходный S-GW→eNB, поскольку не было переключения туннеля вниз от PDN GW на новый целевой S-GW. При наличии физического соединения eNB→ RNC используют вариант Direct Forwarding. Если такого соединения нет, то осуществляют Indirect Forwarding (пунктир на рис. 4.16). Переключение туннеля от PDN GW на целевой S-GW произойдет после выполнения пп.8‒9.
П.5. RNC сообщением Relocation Complete информирует SGSN об успешном завершении процедуры подключения UE к сети UTRAN.
П.6. ММЕ получает от SGSN уведомление Forward Relocation Complete Notification о том, что UE обслуживается сетью UTRAN. Если произошла замена S-GW, то SGSN сообщает об этом ММЕ. Если замены не было, то SGSN может активировать ISR и известить об этом ММЕ в уведомлении. В таком случае ММЕ сохранит и будет вести параллельно с SGSN базу данных абонента. ММЕ подтверждает получение уведомления (п.6а).
ММЕ запускает таймер, по истечении которого будет удален контекст абонента в eNB и исходном S-GW, если он был заменен на целевой. Если трафик вниз идет по варианту Indirect Forwarding, то, получив от ММЕ подтверждение (6а), SGSN также запускает таймер хранения ресурсов в целевом S-GW.
Рис.4.16. Выполнение хэндовера из E-UTRAN в UTRAN
П.7. SGSN приступает к завершающей фазе хэндовера. Он отправляет обслуживающему S-GW сообщение Modify Bearer Request, содержащее адрес SGSN и TEID туннеля сигнализации, адрес SGSN и TEID туннеля трафика при непрямом соединении в UTRAN или адрес RNC и TEID туннеля трафика при прямом соединении (рис.1.6), а также NSAPI каналов трафика [26, гл.15]. Если PDN GW требует информацию о локализации абонента, то SGSN передает дополнительные параметры. Если хэндовер произошел без смены S-GW, то может быть активизирован ISR.
|
|
|
Все сквозные каналы, которые не были сохранены при хэдовере, SGSN деактивирует.
П.8 выполняют при замене S-GW, при смене сети радиодоступа или серьезных изменений в локализации абонента. Если заменен S-GW, то в сообщении Modify Bearer Request целевой S-GW передает PDN GW свой адрес и TEID для организации туннеля вниз на интерфейсе S5/S8. При смене сети радиодоступа или локализации абонента возможны изменения тарифов обслуживания. PDN GW обязательно отвечает подтверждением Modify Bearer Response (п.8а).
П.9. S-GW в сообщении Modify Bearer Response подтверждает переключение соединения вниз (Cause, адрес S-GW и TEID для сигнализации). Теперь трафик вниз следует по маршруту PDN GW→ S-GW→(SGSN)→RNC. Если замены S-GW не было, то сразу после переключения каналов трафика S-GW передает несколько маркерных пакетов по старому пути, сигнализируя о завершении передачи
П.10 выполняется в том случае, когда UE по окончании передачи трафика находит, что он оказался в другой зоне маршрутизации или его временным номером остается GUTI. Тогда UE запускает процедуру Routing Area Update.
П.11. Когда срабатывает таймер, установленный в п.6, ММЕ отправляет eNB команду Release Resources для стирания баз данных абонента в eNB.
Если произошла замена S-GW, то ММЕ сообщением Delete Session Request дает команду исходному S-GW удалить контекст абонента. eNB и S-GW отвечают ММЕ подтверждениями полученных команд.
ПП12 и 13 выполняют в том случае, если произошла замена S-GW и до переключения туннеля трафик вниз из PDN GW шел по варианту Indirect Forwarding. ММЕ дает команду исходному S-GW, а SGSN – целевому S-GW освободить канальный ресурс, выделенный для организации временного туннеля между ними. Оба S-GW подтверждают получение команд.
|
|
|
