 |
Процедура межсистемного хэндовера из UTRAN в E-UTRAN
|
|
|
|
Эта процедура является зеркальной по отношению к хэндоверу, рассмотренному в предыдущем параграфе. Она также состоит из двух фаз: подготовки хэндовера и выполнения хэндовера. Алгоритм первой фазы приведен на рис. 4.17 [20].
Прохождение трафика до начала хэндовера показано на рис.4.17 пунктиром. Процедуру запускает контроллер сети UTRAN RNC (п.1). Он отправляет SGSN сообщение Handover Required, содержащее Cause, идентификатор eNB, идентификатор RNC, контейнер с параметрами UE для выделения ресурсов в eNB, ММЕ и целевом S-GW (п.2). Далее в п.7 ММЕ идентифицирует сквозные каналы, которые надо будет организовать при переключении UE на сеть E-UTRAN.
П.3. Из полученного сообщения SGSN заключает, что RNC запрашивает хэндовер в сеть E-UTRAN. SGSN отправляет ММЕ сообщение Forward Relocation Request о выделении ресурсов для обслуживания абонента, включающее IMSI, идентификатор eNB, Cause, базу данных (контекст) по протоколу ММ, идентификатор текущей сети обслуживания, адрес SGSN и TEID интерфейса для сигнализации, контейнер данных абонента, часовой пояс обслуживания абонента. Сообщение содержит контекст всех сквозных каналов, обслуживающих абонента с
Рис.4.17. Подготовка хэндовера из UTRAN в E-UTRAN
их точками доступа (APN), адреса и TEID туннелей вверх в исходном S-GW. Если активизирован ISR, то он сохраняется активированным и после хэндовера.
Получив сообщение Forward Relocation Request, целевой ММЕ устанавливает сквозные каналы абонента в порядке приоритетов и определяет те каналы, которые сеть не сможет поддерживать. База данных по протоколу ММ обеспечивает выполнение процедур безопасности при обслуживании абонента в сети E-UTRAN. ММЕ определяет максимальную пропускную способность потоков данных абонента через точки доступа.
|
|
|
П.4. ММЕ определяет, следует ли заменить S-GW. Если происходит замена S-GW, то ММЕ направляет ему сообщение Create Session Request. Оно содержит IMSI, адрес ММЕ и TEID для сигнального соединения, адреса PDN GW для пользовательских каналов и сигнальных соединений, PDN GW TEID туннелей вверх в пользовательской и сигнальной плоскостях, тип соединения на S5/S8 (IPv4 или IPv6). Требуемый тип протокола устанавливает S-GW.
S-GW выделяет ресурс для обслуживания абонента и отвечает сообщением Create Session Response (адреса S-GW в пользовательской и сигнальной плоскостях, TEID туннелей вверх в пользовательской и сигнальной плоскостях) – п.4а.
П.5. ММЕ посылает запрос Relocation Request на целевой eNB для выделения канального ресурса и организации сквозных каналов В запросе передают идентификатор UE, Cause, базу данных для выполнения процедур безопасности, список сквозных каналов с их параметрами, контейнер данных UE, информацию об ограничениях доступа абонента к ресурсам сети при хэндоверах. В запрос также включают адрес S-GW в пользовательской плоскости и TEID для туннелей вверх. eNB выделяет ресурсы для организации запрошенных сквозных каналов.
П.5а. В обратном сообщении Relocation Request Acknowledge eNB отправляет контейнер для RNC, список установленных сквозных каналов и, если есть таковые, список каналов, которые не установлены и чей контекст будет деактивирован. Теперь eNB готов принимать пакеты данных абонента в направлении вниз по организованным сквозным каналам.
П.6 выполняют в случае замены S-GW и создания обходного пути (Indirect Forwarding) для трафика вниз в процессе хэндовера. В сообщении Create Indirect Data Forwarding Tunnel Request целевой S-GW получает адрес и TEID eNB. В обратном сообщении Create Indirect Data Forwarding Tunnel Response S-GW передает свой адрес и TEID (п.6а).
П.7. ММЕ отправляет SGSN ответ Forward Relocation Response (Cause, адрес ММЕ и TEID для сигнализации, контейнер для UE, индикатор замены S-GW, информация об организации сквозных каналов в сети Е-UTRAN и параметры для организации промежуточных туннелей при передаче трафика вниз в процессе хэндовера).
|
|
|
Если не было замены S-GW или была замена, но существует прямое физическое соединение между исходным RNC и целевым eNB (Direct Forwarding), то сообщают адрес и TEID eNB для каналов трафика.
Если нет физического соединения между исходным RNC и целевым eNB (Indirect Forwarding) и произошла замена исходного S-GW на целевой, то сообщают адрес и TEID целевого S-GW.
П.8 выполняют при организации Indirect Forwarding. SGSN направляет в S-GW, используемый при Indirect Forwarding, сообщение Create Indirect Data Forwarding Tunnel Request, содержащее идентификаторы сквозных каналов, адрес и TEID, полученные SGSN в п.7. Обычно этим S-GW является исходный S-GW, но может быть и другой обслуживающий шлюз. В ответном сообщении Create Indirect Data Forwarding Tunnel Response (п.8а) S-GW сообщает свой адрес и TEID для организации временного туннеля.
Алгоритм следующей фазы выполнения хэндовера показан на рис. 4.18.
П.1. SGSN завершает подготовку к хэндоверу, посылая RNC Handover Command, содержащую контейнер для RNC, список сквозных каналов, которые следует деактивировать, и каналов, которые надо организовать для временной передачи трафика вниз (RABs Subject to Data forwarding list). Для организации этих каналов eNB получает адреса и TEID, которые были пересланы SGSN в пп. 7 при Direct Forwarding или 8а при Indirect Forwarding подготовительной фазы (рис. 4.16). В результате будет обеспечен либо прямой путь передачи данных RNC→eNB, либо обходной через исходный S-GW в зависимости от конфигурации сети. Если в сети UTRAN был непрямой туннель трафика (через SGSN), то при Indirect Forwarding RNC получает для обходного туннеля адрес и TEID SGSN.
П.2. RNC посылает UE команду выполнить хэндовер. В этой команде UE передают контейнер, содержащий необходимые для хэндовера параметры, которые eNB загрузил в контейнер в подготовительной фазе. Приняв команду, UE останавливает передачу трафика вверх, устанавливает соответствие идентифи каторов сквозных каналов в Е-UTRAN с NSAPI каналов в UTRAN и выполняет процедуру доступа к сети Е-UTRAN (п.4).
Рис.4.18. Выполнение хэндовера из UTRAN в E-UTRAN
П.5. Получив доступ к eNB, UE отправляет ему сообщение HO to E-UTRAN complete.
П.6. Сообщением Handover Notify eNB информирует ММЕ о завершении подключения UE к сети Е-UTRAN.
П.7. SGSN получает от MME уведомление Forward Relocation Complete Notification о том, что UE обслуживается сетью UTRAN. Если произошла замена S-GW, то ММЕ сообщает об этом SGSN. Если замены не было, то SGSN может активировать ISR и известить об этом ММЕ в уведомлении. В таком случае SGSN сохранит и будет вести параллельно с ММЕ базу данных абонента. SGSN подтверждает получение уведомления (п.7а).
|
|
|
SGSN запускает таймер, по истечении которого будет удален контекст абонента в RNC и исходном S-GW, если он был заменен на целевой. Если трафик вниз идет по варианту Indirect Forwarding, то, получив от SGSN подтверждение (7а), ММЕ также запускает таймер хранения ресурсов в целевом S-GW.
П.8. ММЕ приступает к завершающей фазе хэндовера. Он отправляет обслуживающему S-GW сообщение Modify Bearer Request, содержащее Cause, адрес MME и TEID туннеля сигнализации, адрес eNB и TEID туннеля трафика вниз, идентификаторы сквозных каналов. Если PDN GW требует информацию о локализации абонента, то ММЕ передает дополнительные параметры. Если хэндовер произошел без смены S-GW, то может быть активизирован ISR.
Все сквозные каналы, которые не были сохранены при хэдовере, ММЕ деактивирует.
П.9 выполняют при замене S-GW, при смене сети радиодоступа или серьезных изменений в локализации абонента. Если заменен S-GW, то в сообщении Modify Bearer Request целевой S-GW передает PDN GW свой адрес и TEID для организации туннеля вниз на интерфейсе S5/S8. При смене сети радиодоступа или локализации абонента возможны изменения тарифов обслуживания. PDN GW обязательно отвечает подтверждением Modify Bearer Response (п.9а).
П.10. S-GW в сообщении Modify Bearer Response подтверждает переключение соединения вниз (Cause, адрес S-GW и TEID для сигнализации). Теперь трафик вниз следует по маршруту PDN GW→ S-GW→eNB. Если замены S-GW не было, то сразу после переключения каналов трафика S-GW передает несколько маркерных пакетов по старому пути, сигнализируя о завершении передачи
П.11 выполняется в том случае, когда UE по окончании передачи трафика находит, что необходимо запустить процедуру Tracking Area Update.
П.12. Когда срабатывает таймер, установленный в п.7, SGSN отправляет RNC Release Command для стирания в нем базы данных абонента. RNC отвечает подтверждением Release Complete.
|
|
|
Если произошла замена S-GW, то SGSN сообщением Delete Session Request дает команду исходному S-GW удалить контекст абонента. S-GW отвечают SGSN подтверждением полученной команды.
ПП13 и 14 выполняют в том случае, если произошла замена S-GW и до переключения туннеля трафик вниз из PDN GW шел по варианту Indirect Forwarding. SGSN дает команду исходному S-GW, а ММЕ – целевому S-GW освободить канальный ресурс, выделенный для организации временного туннеля между ними. Оба S-GW подтверждают получение команд.
Контрольные вопросы к главе 4.
1. Каково назначение процедуры RRC connection establishment? В каком состоянии находится UE до процедуры и по ее завершении?
2. Каково назначение процедуры Attach? Какие функциональные элементы в ней участвуют?
3. Какие каналы организуют в сети по завершении процедуры Attach?
4. В каких случаях происходит запуск процедуры Tracking Area Update?
5. Какие функциональные элементы участвуют в процедуре Tracking Area Update?
6. Какие соединения сквозных каналов остаются в сети после перевода станции в состояние IDLE?
7. В чем состоит назначение процедуры Service Request и в каких случаях ее запускают?
8. Опишите, что происходит при организации (активации) сквозного канала.
9. В чем сходство и различия процедур активации и изменения парамтров качества сквозного канала?
10. Из каких этапов состоит процедура внутрисистемного хэндовера?
11. Что происходит на 3 этапе хэндовера – “запаздывающем переключении”? Почему на соединении S-GW – eNB переключают только туннель вниз?
12. Что происходит на подготовительном этапе при межсистемных хэндоверах?
13. Как переключают сквозные каналы вверх и вниз при межсистемном хэндовере?
Литература
1. Системы и сети радиодоступа 4G: LTE, WiMAX/А.Е.Рыжков А.Е., М.А.Сиверс В.О.Воробьев, А.С.Гусаров, А.С.Слышков, Р.В.Шуньков. – СПб: Линк, 2012. – 226с.
2. Бабков В.Ю., Цикин И.А. Сотовые системы мобильной радиосвязи. – СПб.: Изд-во Политехн. Ун-та, 2011. – 426с.
3. 3GPP TS 29.281; General Packet Radio System (GPRS); Tunnelling Protocol User Plane (GTPv1-U)
4. 3GPP TS 29.274; Evolved General Packet Radio Service (GPRS); Tunnelling Protocol for Control plane (GTPv2-C); Stage 3
5. 3GPP TS 36.300; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage2.
6. Nupur Rastogi, Ragiv Gupta. LTE Advanced – LIPA and SIPTO, Jul.2012.- http://info.aricent.com/LIPA_SIPTO_Whitepaper_Registration_aw.html
7. 3GPP TR 23.829; Local IP Access and Selected IP Traffic Offload (LIPA-SIPTO)
8. 3GPP TR 23.859; LIPA Mobility and SIPTO at the Local Network
9. 3GPP TS 36.211; Physical Channels and Modulation
10. 3GPP TS 36.101; User Equipment (UE) radio transmission and reception
11. 3GPP TS 36.331; Radio Resource Control (RRC)
12. MIMO-OFDM for LTE, Wi-Fi and WiMAX: Coherent versus Non-coherent and Cooperative Turbo-transceivers/L.Hanzo, Y.Akhtman, Li Wang, Ming Yiang. – Chichester, 2011. – 658p.
13. Dahlman E., Parkval S, Sköld J. 4G LTE/LTE-Advanced for Mobile Broadcast.- Oxford, 2011.- 431p.
14. Шлома А.М., Бакулин М.Г., Крейнделин В.Б., Шумов А.П. Новые алгоритмы формирования и обработки сигналов в системах подвижной связи. -М.: Горячая линия.-Телеком, 2008.-344с.
|
|
|
15. Evolution of Reference Signals for LTE-Advanced Systems/ Young-Han Nam, Yosuke Akimoto, Younsun Kim and oth – IEEE Communications Magazine, Feb. 2012.- p.132-138.
16. Coordinated Multipoint Transmission and Reception in LTE-Advanced: Deployment Scenarios and Operational Challenge/D.Lee, H.Seo, B.Clerckx and oth – IEEE Communications Magazine, Feb. 2012.- p.148-155.
17. Kuldeep Kumar A comparison of different detection algorithms in a MIMO system/ International Journal of Advanced Engineering Sciences and Technologies.- 2011, Vol 7, No. 2 - p.301 – 304.
18. Overview of 3GPP LTE-Advanced Carrier Aggregation for 4G Wireless Communications/ Z. Shen, A. Papasakellariou, J. Montojo and oth. – IEEE Communications Magazine, Feb. 2012.- p.122-130.
19. 3GPP TS 23.203; Policy and charging control architecture
20. 3GPP TS 23.401; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access
21. 3GPP TS 36.213; Physical layer procedures
22. 3GPP TS 36.321; Medium Access Control (MAC) protocol specification
23. 3GPP TS 36.413; S1 Application Protocol (S1 AP)
24. 3GPP TS 22.042; Network Identity and TimeZone (NITZ); Service description; Stage1
25. 3GPP TS 43.129; Packet-switched handover for GERAN A/Gb mode; Stage 2
26. Телекоммуникационные технологии: введение в технологии GSM/ С.Б.Макаров, Н.В.Певцов, Е.А.Попов, М.А.Сиверс – М.: Издательский центр “Академия”, 2006. – 256c.
27. Скрынников В.Г. Радиоподсистемы UMTS/LTE. Теория и практика. – М.: Спорт и Культура – 2000, 2012. – 864с.
|
|
|
