Внутрішньосистемний хендовер (lte intra-system handover)

Так як користувачі стільникових мереж зв'язку є мобільними і можуть під час сеансів зв'язку пересуватися (через що радіоусловія, в яких знаходяться абонентські станції, постійно змінюються), необхідно підтримати процедури, що дозволяють надавати безперервний сервіс абонентам, навіть під час їх переміщення. Для цього використовується процедура хендовера (handover). Ця процедура дозволяє переключити обслуговування мобільної станції з однієї базової станції (БС) на іншу БС (як правило, має більш якісне з'єднання з мобільною станцією, але не завжди).

Хендовер може бути виконаний для мобільних станцій, які знаходяться в активному стані та зареєстровані в мережі (стан ECM-CONNECTED). При цьому, технологія LTE не підтримує так звані 'м'які' хендовери (soft handover). Тобто, все хендовери в LTE є 'жорсткими' (hard handover). Розглянемо як відбувається процедура хендовера в LTE, тобто перемикання обслуговування мобільної станції від однієї БС до іншої.

На малюнку нижче процедура хендовера (HO, handover) представлена ​​по кроках. Як видно з малюнка, вся процедура ділиться на три наступних етапи: підготовка, виконання та завершення хендовера. Етапи підготовки і виконання виконуються в мережі радіо доступу (Radio Access Network). Останній етап - завершення хендовера задейтсвует як мережу радіо доступу, так і опорну мережу (Core Network).

Внутрішньосистемний хендовер (lte intra-system handover)

БС повідомляє мобільної станції (МС) в яких ситуаціях необхідно відправляти звіти про вимірювання (Measurement reports). Для цього використовується повідомлення RRC Connection Reconfiguration. Всього стандартом визначено 5 умов, при яких можлива відправка звітів, і називаються вони подіями (Events) з номерами від A1 до A5. Для активації внутрісистемного хендовера найбільше підходять події A3 і A5. Перше означає, що сигнал від сусідньої БС перевищив сигнал від обслуговуючої БС на задану величину. А друге - сигнал від обслуговуючої БС став гірше, ніж задане значення 1, в той час як сигнал від сусідньої БС став краще, ніж задане значення 2.

Як тільки МС виявляє, що дотримуються умови для одного із заданих подій (A1-A5), вона відправляє звіт про вимірювання (крок 3 на малюнку). У цьому повідомленні МС повідомляє значення RSRP і RSRQ для обслуговуючого і сусіднього секторів. А також фізичний ідентифікатор сусіднього сектора (PCI - Physical Cell Identity). Глобальний ідентифікатор сектора (CGI - Cell Global Identity) передається тільки в разі спеціального запиту від БС, так як для того, щоб його дізнатися, МС необхідно прийняти блоки MIB і SIB від сусідньої БС. Це може знадобитися тоді, коли ідентифікатора PCI сусіднього сектора недостатньо для визначення сусідньої БС. Наприклад, під час використання функціональності автоматичного визначення сусідів (ANR - Automatic Neighbour Relation), коли сусідні БС не прописані в конфігураційних файлах. Якщо сусідня БС вже є в базі даних обслуговуючої БС, тоді буде достатньо ідентифікатора PCI.

Якщо обслуговуючої БС вдалося визначити сусідню БС і дотримуються умови для здійснення хендовера, то обслуговуюча БС ініціює процедуру хендовера, відправляючи повідомлення Handover Request по інтерфейсу X2 сусідній БС (крок 5 на малюнку). Це повідомлення містить інформацію про МС (так званий контекст МС), а так же причину скоєння хендовера. Якщо хендовер відбувається через погіршення якості радіосоедіненія з обслуговуючої БС і його поліпшення з сусідньої БС, то причина буде визначена як 'Handover Desirable for Radio Reasons'. Також причиною хендовера може бути розподіл навантаження в мережі (можливі варіанти: 'Resource Optimisation Handover' і 'Reduce Load in Serving Cell'). В контексті МС передається інформація про те, які з'єднання необхідно створити на сусідній БС для того, щоб обслужити мобільний пристрій. Крім цього, в повідомленні Handover Request передається глобальний ідентифікатор сектора (CGI), в який переміщається МС, і ідентифікатор вузла MME (GUMMEI - Globally Unique MME Identity), на якому в поточний момент зареєстрована МС. Цей ідентифікатор необхідний для здійснення дій на заключному етапі хендовера.

Після відправки повідомлення 'RRC Connection Reconfiguration' обслуговуючої БС починається етап виконання хендовера. Для того, щоб не відбулася втрата призначених для користувача даних, яка обслуговує БС передає повідомлення 'SN Status Transfer' сусідній БС, а також наявні призначені для користувача дані. У повідомленні 'SN Status Transfer' передаються номери PDCP SN (Sequence Number) для низхідного і висхідного з'єднань (якщо вони використовують режим передачі з підтвердженнями на рівні RLC). Для спадного з'єднання передається значення PDCP SN то, яке має бути призначене сусідній БС при передачі першого пакету МС. Для висхідного з'єднання обов'язково передається значення PDCP SN, відповідне пакету даних, який повинен бути прийнятий наступним. Крім цього, для восходяшего з'єднання може передаватися бітова маска для вказівки пакетів даних, які не були успішно передані і повинні бути передані повторно (використовується в тих випадку, коли є "пропуски" в послідовності успішно прийнятих пакетів).

В цей час, МС від'єднується від обслуговуючої БС (процедура Detach) і синхронізується з сусідньої БС. Для другої дії МС обробляє сигнали первинної і вторинної синхронізації (PSS і SSS). Після цього, МС виконує процедуру випадкового доступу (Random Access), в процесі якої МС відправляє RA-преамбулу. Процедура випадкового доступу може бути з колізіями (contention based), так і без колізій (non-contention based). Для того, щоб уникнути колізій і зменшити час виконання процедури хендовера, БС може зарезервувати певну RA-преамбулу для МС і повідомити про це в повідомленні 'RRC Connection Reconfiguration' (Dedicated RACH Configuration). Якщо ж БС цього не робить, то МС виконує звичайну процедуру випадкового доступу, в якій можливі колізії.

У відповідь на RA-преамбулу БС відправляє повідомлення RAR (Random Access Response), в якому, якщо необхідно, коректує тимчасову підстроювання МС (Timing Advance). Так само в цьому повідомленні передається інформація про виділений МС ресурсі для передачі L3 повідомлення - 'RRC Connection Reconfiguration Complete'. Коли МС відправить це повідомлення з її точки зору процедура хендовера є завершеною.

Після відправки повідомлення 'RRC Connection Reconfiguration Complete' мобільною станцією, процедура хендовера переходить в завершальну фазу виконання (HO Completion). У цей момент часу МС і БС можуть обмінюватися даними в обох навправленіях: низхідному і висхідному. Однак, на ділянці між БС і обслуговуючим шлюзом (S-GW - Serving Gateway) БС може відправляти висхідний трафік, а спадний трафік від обслуговуючого шлюзу все ще передається на "стару" БС, після перенаправляється на сусідню БС по інтерфейсу X2. Для того, щоб обслуговуючий шлюз відправляв спадний трафік відразу на сусідню БС, потрібно оновити установки відповідного GTP тунелю. Для цього БС відправляє повідомлення 'Path Switch Request' на вузол MME. У цьому повідомленні вказується нова кінцева точка для GTP тунелю (TEID - Tunnel Endpoint Identity), відповідна сусідній БС. Крім цього, там передаються ідентифікатор зони спостереження (TAI - Tracking Area Identity) і ідентифікатор сектора, на якому зараз зареєстрована МС (CGI - Cell Global Identity).

Після отримання повідомлення 'Path Switch Request' вузол MME вирішує чи зможе поточний обслуговуючий шлюз і далі обслуговувати дану МС. На малюнку вище зображено випадок, коли зміна обслуговуючого шлюзу не потрібно. Якщо ж зміна обслуговуючого шлюзу необхідна, то MME відправляє повідомлення 'Create Session Request' новому обслуговуючому шлюзу, і той вже коммуницирует з PDN шлюзом, щоб перенаправити спадний потік даних існуючого GTP тунелю. У нашому випадку (без зміни обслуговуючого шлюзу), MME відправляє повідомлення 'Modify Bearer Request' обслуговуючому шлюзу. Отримавши це повідомлення, обслуговуючий шлюз розуміє, що тепер необхідно відправляти спадний трафік інший (сусідній) БС. Після чого МС і обслуговуючий шлюз можуть обмінюватися даними безпосередньо, без залучення 'старої' БС.

Якщо ви не знайшли цікаву для вас інформацію по LTE / LTE-A в цій статті, напишіть мені про це лист на [email protected]. Я постараюся її додати в найкоротші терміни.