Вы начали звонок, когда были подключены по Wi‑Fi, выходите из помещения, Wi‑Fi пропадает, телефон переключается на LTE — а разговор продолжается, как будто ничего не произошло. 

Для пользователя это выглядит просто. Для сети — это десятки процедур, которые должны отработать в строгом порядке за доли секунды.

Меня зовут Алексей Червяков, я разработчик и тимлид в компании VAS Experts. Когда мы делали свой ePDG для Wi-Fi Calling, стало понятно, что одной только работы через Wi‑Fi недостаточно: нужно еще сохранить активный вызов в момент перехода устройства между Wi‑Fi и LTE.

Наш ePDG умеет это в обе стороны, но в статье разберем один сценарий — из Wi‑Fi в LTE, расскажу что такое хэндовер и покажу процесс изнутри.

Что такое handover

Когда меня спрашивают, что из себя представляет хэндовер (handover), я часто объясняю это на примере аналогии с эстафетой. Бегун несет палочку и на границе своего этапа передает ее следующему. Для зрителя движение непрерывно, но сама передача должна случиться вовремя: отпустишь палочку рано — она упадет, примешь поздно — потеряешь скорость.

В сети «палочка» — это абонентская сессия: контекст абонента, маршрут трафика и параметры активного звонка. Пока абонент находится в зоне одной соты или одной технологии радиодоступа, его сессию обслуживает текущий участок сети. Когда условия меняются, сеть передает обслуживание дальше: сохраняет контекст абонента, маршрут трафика и параметры активной сессии, чтобы звонок или передача данных не оборвались.

Handover, или хэндовер (от англ. hand over — «передавать») — процедура переключения обслуживания абонентского терминала (телефона) с одной соты (или технологии радиодоступа) на другую без разрыва соединения или с минимальной паузой.

Зачем он вообще нужен:

• Для непрерывной связи при движении

При движении абонента сигнал от текущей соты слабеет, а от соседней усиливается. Хэндовер позволяет вовремя переключить устройство, чтобы избежать обрыва звонка или передачи данных.

• Балансировка нагрузки

Если одна сота перегружена, сеть может перевести часть абонентов на соседнюю или на другую частоту. Это помогает распределить нагрузку и сохранить стабильную работу сети.

• Для сохранения качества связи. 

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

С чего все начинается

Разбираем переход из Wi‑Fi в LTE, то есть из non-3GPP-доступа в 3GPP-доступ. В Wi-Fi Calling голос идет через зашифрованный туннель до ePDG, в LTE — через базовую станцию и пакетное ядро.

Хэндовер здесь — это сборка из нескольких процедур, которые должны пройти по порядку:

1. телефон цепляется к LTE и аутентифицируется;

2. сеть обновляет данные об абоненте;

3. перестраивается маршрут трафика, сохраняя IP-адрес;

4. телефон заново регистрируется в IMS уже через LTE;

5. под голос поднимается выделенный bearer (dedicated bearer);

6. старая Wi-Fi-сессия закрывается.

Если хоть один шаг отработает не так — звонок либо упадет, либо в сети повиснут «мусорные» сессии.

Спойлер: нам удалось реализовать все процедуры и проверить его на тестовом стенде. При переходе с Wi-Fi на LTE вызов сохраняется, а сетевые элементы отрабатывают переход так, как должны.

Ниже покажем это на видео.

А теперь разберем, что в этот момент происходит на стороне сети.

Участники процесса

Прежде познакомимся с участниками процесса.

Дальше эти элементы будут встречаться постоянно. Держите таблицу под рукой — к ней можно возвращаться.

Как это работает: по фазам

Фаза 0. Исходное состояние: звонок через Wi-Fi

В исходном состоянии телефон обслуживается через Wi-Fi. ePDG инициирует процедуру аутентификации абонента через HSS, и только после её успешного завершения между устройством абонента и ePDG поднимается IPSec-туннель. Затем ePDG авторизует абонента на PGW, после чего поднимается GTP-туннель.

Через IPSec-GTP-туннель устройство абонента подключается во внутреннюю сеть оператора, в которой располагается IMS сервер. После этого устройство регистрируется в IMS, так же с помощью HSS. Только после успешного завершения этой процедуры устройство становится доступным для VoWiFi и может инициировать или принимать вызовы.

Фаза 1. Телефон видит LTE

Устройство обнаруживает доступную LTE-сеть и решает начать хэндовер. После этого базовая станция (eNodeB) инициирует сигнальный обмен с MME. 

На этом этапе голосовой сервис уже работает, но LTE-доступ еще не участвует в обслуживании вызова.

Колл-флоу — большая и детальная схема, и формат Хабра не позволяет показать ее во всей красе. Поэтому для всех, кому интересно рассмотреть детали, мы оставили по ссылке большой PDF в хорошем качестве.

Фаза 2. Аутентификация в LTE

Устройство абонента подключается к eNodeB и взаимодействует только с ним. eNodeB, в свою очередь, взаимодействует с MME: MME обращается к HSS, чтобы проверить абонента и получить необходимые данные для регистрации в LTE. 

После ответа HSS начинается процедура attach, в ходе которой выполняются аутентификация абонента и настройка радиоканала. По завершении аутентификации MME выделяет ресурсы ядра сети для реализации требуемого сервиса и дальнейшей пользовательской сессии.

В этот момент сеть должна убедиться, что устройство действительно может обслуживаться в LTE и что для него можно создать корректный пользовательский путь.

Фаза 3. Обновление местоположения в HSS

После успешной аутентификации абонента MME отправляет в HSS запрос на обновление местоположения. HSS фиксирует, что абонент теперь обслуживается в LTE. При этом Wi-Fi-доступ еще может оставаться активным, поэтому в профиле абонента некоторое время видны обе технологии.

Этот момент важен для бесшовности. Сеть не должна резко «забыть» старый доступ до того, как новый путь будет готов принять сервис.

Фаза 4. Создание PDN-сессии

Затем начинается создание PDN-сессии. В обмене участвуют MME, SGW, PGW и UPF. 

PGW остается якорной точкой подключения абонента к внешним сетям. При переходе из Wi‑Fi Calling в LTE меняется только путь доставки трафика: на замену ePDG(WiFi) приходит SGW (LTE), а может и SGSN(3G), тогда как PGW остается прежним — именно он выдает абоненту IP-адрес и агрегирует несколько каналов доступа на один IP-адрес абонента.

Если в схеме используется PCEF, на этом этапе запрашиваются PCC-правила, а DPI получает информацию о новой сессии.

После создания PDN-сессии абонент получает возможность передачи данных через LTE. Однако для переноса голосового вызова требуется дополнительный этап — регистрация в IMS и выделение отдельного bearer для голосового трафика.

Фаза 5. Перерегистрация в IMS через LTE

После появления доступа в LTE телефон начинает регистрацию в IMS через LTE. IMS обменивается данными с HSS. После успешной регистрации телефон готов к VoLTE-вызовам.

Здесь важно не только получить статус «зарегистрирован». Нужно, чтобы все участники процесса согласованно понимали, каким образом теперь должен обслуживаться голос.

Фаза 6. Выделенный bearer под VoLTE

Когда устройство инициирует или принимает VoLTE-вызов, сеть начинает процедуру создания выделенного bearer для голосового трафика. В процессе участвуют IMS, PGW, SGW, MME и eNodeB. В результате формируется выделенный bearer с QCI = 1, предназначенный специально для передачи голоса.

Обычный интернет-трафик может пережить задержки или повторную передачу пакетов. Голосовой поток значительно чувствительнее к задержкам, джиттеру и потерям, поэтому для него выделяется отдельный bearer с гарантированными параметрами обслуживания.

После завершения этой процедуры сеть готова передавать голосовой трафик по LTE с необходимыми параметрами качества. Если этап создания выделенного bearer не отработает корректно, вызов не будет установлен или будет прерван.

Фаза 7. Закрытие Wi-Fi-сессии

После перехода в LTE Wi-Fi-сессия больше не нужна для обслуживания вызова. В промышленной схеме SMF может деактивировать S2b-сессию автоматически в ходе процедуры хендовера. В нашем тестовом сценарии автоматическая деактивация отключена, поэтому Wi-Fi-сессия удаляется отдельно, когда это необходимо.

Телефон закрывает IPSec-туннель, после чего освобождаются ресурсы и удаляются состояния, связанные с подключением через ePDG. После этого закрывается PCC-сессия, DPI получает уведомление об удалении соответствующей сессии, и сеть завершает переход устройства в LTE.

Этот этап легко недооценить. Если старая сессия не закрылась корректно, в сети могут остаться лишние состояния: туннель уже не используется, но записи еще могут оставаться в узлах. Поэтому финальная деактивация так же важна, как и сам переход вызова.

То же самое, но в логах сети

Выше была архитектура. Теперь — как этот сценарий выглядит в реальных логах.

Шаг 1. Старт: телефон в IMS через Wi-Fi

12:12:01 [Kamailio] REGISTER challenge 401 ... (IPSec setup)  # сервер шлет challenge
12:12:01 [Kamailio] AUTH success ...                      # повторный REGISTER уже по IPSec
12:12:02 [Kamailio] REGISTER success ... contact=10.46.0.61

Результат: за устройством закрепился IMS-адрес 10.46.0.61. Запомните его — это главная контрольная точка всего сценария. Если при переходе в LTE он изменится, голосовую сессию придется пересобирать с нуля.

Шаг 2. Начинается звонок

12:12:52 [SMF] [Rx] AA-Request received
12:12:52 [SMF] [Rx] Found session for IPv4:10.46.0.58 APN=ims     # привязка к IMS-сессии второго абонента (iPhone)
12:12:52 [SMF] PCC rule 'rx-audio-1': QCI=1 GBR=84000/84000 MBR=84000/84000
12:12:52 [SMF] AA-Answer sent (SUCCESS, 1 PCC rules)

Результат: звонок идет между двумя VoWiFi-телефонами. QoS-ресурс под голос (QCI=1, ~84 кбит/с — это AMR-WB) сеть выделяет под конкретный медиапоток. Появление QCI=1 — момент, когда звонок занял гарантированный канал.

Шаг 3. Телефон цепляется к LTE

12:13:06 [MME] InitialUEMessage
12:13:06 [MME] Attach request
12:13:06 [SMF] GTPv2 Create Session: APN[internet] RAT_TYPE[6]
12:13:06 [MME] Attach complete

Результат: RAT_TYPE[6] — это EUTRAN, то есть LTE. Поднялась обычная сессия по APN internet. Голос пока полностью на Wi-Fi.

Шаг 4. Голосовая сессия переезжает на LTE

12:13:25 [SMF] GTPv2 Create Session: APN[ims] RAT_TYPE[6]
12:13:25 [SMF] Handover IP reuse: copying IPv4[10.46.0.61] from WLAN session   # ключевая строка
12:13:25 [SMF] UE IMSI[...] APN[ims] IPv4[10.46.0.61]
12:13:25 [SMF] QCI[5] sending to SGW ... EBI[6] APN[ims]
12:13:25 [SMF] Handover Non-3GPP→3GPP: skipping WLAN deactivation for APN[ims] (coexistence mode)
12:13:25 [UPF] SRC:0A2E003C, UE:0A2E003D                       # UPF поднял новый LTE data path для 10.46.0.61

Результат: Handover IP reuse — вот оно. SMF переносит тот же IP 10.46.0.61 из Wi-Fi-сессии в новую LTE-сессию. Адрес не сменился — значит, активный разговор не надо устанавливать заново. Это и есть признак корректного handover: доступ поменялся, сессия с голосом — нет.

Шаг 5. Старый Wi-Fi-путь закрывается

12:13:25 [SMF] Modify Bearer: Handover Indication (Non-3GPP to 3GPP), RAT=6, APN=ims
12:13:25 [SMF] Handover: deactivating WLAN session ... via PFCP
12:13:25 [SMF] GTP Cause [Value:87]

Результат: Non-3GPP to 3GPP — направление перехода (с Wi-Fi через ePDG на LTE). GTP Cause 87 — запрос отработал успешно. Для нас это значит, что Wi-Fi-сессия закрыта штатно, без зависших состояний.

Шаг 6. Звонок завершает пользователь

12:13:44 [SMF] [Rx] Session-Termination-Request received
12:13:44 [SMF] [Rx] Removing PCC rule 'rx-audio-1'
12:13:44 [SMF] [Rx] Session-Termination-Answer sent (SUCCESS)

Результат: финальное доказательство — хэндовер не уронил звонок. Сеть успела перевести обслуживание на LTE, а разговор закончился по воле человека, а не из-за сбоя.

Шаг 7. Отложенная чистка старой Wi-Fi-сессии

12:14:19 [UPF] [Removed] Number of UPF-sessions is now 10
12:14:19 [SMF] Removed Session: UE IMSI:[...] DNN:[ims:0] IPv4:[10.46.0.61]
12:14:19 [MME] Removed Session: UE IMSI:[...] APN:[ims]

Результат: вот те самые «висящие состояния», о которых я говорил выше. 

Обратите внимание на время: звонок закончился в 12:13:44, а финальная зачистка WLAN-сессии прошла только в 12:14:19 — спустя ~35 секунд. Это нормально, старый путь держится как страховка, но если такая чистка вообще не отработает, в узлах копится мусор. Поэтому мы отдельно проверяли, что сессия реально удаляется.

Что в итоге

Handover из Wi-Fi в LTE — это не «телефон переключился», а согласованная работа радиодоступа, EPC, IMS и узлов политик. Для абонента все незаметно. Для сети это цепочка процедур, где критична одна вещь: сохранить ту сессию, на которой держится голос (в нашем случае — IP-адрес 10.46.0.61), пока строится новый путь, и только потом аккуратно убрать старый.

Главные грабли, на которые стоит обратить внимание, если будете делать похожее:

• не дать смениться IP при переезде сессии — иначе понадобится пересборка звонка;

• не «забыть» про старый доступ раньше, чем будет готов новый;

• обязательно дочищать Wi-Fi-сессию, иначе в узлах копится «мусор».

Если соберетесь копать глубже — вот спецификации, по которым мы сверялись:

• 3GPP TS 23.401 — архитектура EPC и LTE handover

• 3GPP TS 23.402 — взаимодействие LTE/5G с Wi-Fi и другими non-3GPP сетями

• 3GPP TS 24.302 — сигнализация UE ↔ EPC через Wi-Fi

• 3GPP TS 23.237 — сохранение IMS-вызова при смене доступа

• GSMA IR.51 — практические рекомендации по VoLTE/VoWiFi