5G особые требования: общие аспекты. Часть 10.
При другом варианте протоколы транспортного уровня без установления соединения, такие как UDP, устраняют необходимость в подтверждении связи и повторных передачах. Однако эти улучшения в задержке происходят за счет снижения надежности, поскольку UDP, хотя и подходит для критически важного трафика, чувствительного ко времени, не обеспечивает средства для восстановления после потери пакетов. В этом смысле оба этих традиционных протокола транспортного уровня не подходят для рассматриваемых случаев использования, где безошибочный прием пакетов в пределах задержки имеет первостепенное значение.
Для удовлетворения экстремальных требований при проектировании нового протокола транспортного уровня следует совместно учитывать как задержку, так и надежность при эффективном балансе компромисса между этими двумя показателями производительности. С этой целью новый протокол должен иметь возможность множественной адресации и по своей сути поддерживать передачу по нескольким резервным дорожкам. В этом отношении новый протокол аналогичен существующим многолучевым протоколам, таким как MP-TCP и SCTP.
Однако, в отличие от существующих протоколов, резервные дорожки следует использовать для передачи дублированных пакетов, а не для достижения более высокой пропускной способности и распределения нагрузки. Кроме того, выбор резервных каналов передачи должен выполняться таким образом, чтобы поток трафика на каждом пути был изолированным и некоррелированным на сквозной основе для обеспечения максимальной надежности.
Новый транспортный протокол также должен поддерживать работу без сохранения состояния и разрешать проактивную автономную повторную передачу пакетов по разным путям, не требуя явных сообщений подтверждения от принимающего объекта. Этот подход может применяться для устранения любой дополнительной задержки RTT, в то же время удовлетворяя цели сквозной надежности. Автономная повторная передача аналогична дублированию пакетов. Решение активировать и деактивировать дублирование основано на приеме ACK в течение предварительно определенной продолжительности на одной дорожке. Если ACK не был получен во временном окне, протокол может автоматически начать отправку повторных передач по отдельному пути. Потенциальным протоколом транспортного уровня, который может быть применим для случаев использования с экстремальными требованиями, является основанный на UDP многолучевой QUIC [28], однако могут потребоваться дополнительные усовершенствования для поддержки одновременной передачи дублированных пакетов.
Следует отметить, что даже в случае, когда между уровнями приложений в UE и сервере приложений установлено множество логических соединений UDP, нет гарантии, что дублированные пакеты не будут мультиплексированы в общих туннелях и будут проходить через независимые пути в CN, тем самым избегая любых отдельные точки нарушений. В связи с этим, осведомленность о конфигурациях протокола UPF и туннелирования в приложении, а также осведомленность о конфигурациях протокола транспортного уровня на уровне CN / NAS могут быть необходимы для поддержки экстремальных требований на сквозной основе.
В целом, маршрутизация пакетов на сервер приложений и от него через Интернет может привести к непредсказуемым задержкам и потерям пакетов. Кроме того, использование централизованного сервера приложений и его удаленное определение местоположения для обеспечения более широкого охвата услуг может привести к условиям перегрузки, а также к очереди пакетов и задержке, связанной с обработкой, как на узлах пересылки, так и на сервере приложений.
Для рассмотренных вариантов целевого использования ключевым аспектом, который необходимо принимать во внимание, является потенциальное развертывание сервера приложений в граничном узле, расположенном в непосредственной близости от RAN и CN. В другом сценарии сервер приложений может быть размещен в частной сети, напрямую доступной из CN. В обоих этих сценариях сгенерированные пакеты не должны проходить через Интернет, и, следовательно, методы управления потоком и управления перегрузкой, обычно обрабатываемые транспортным уровнем, могут быть перемещены на уровень приложения. Это значительно упрощает разработку протоколов как сетевого, так и транспортного уровня, которые, в свою очередь, могут быть более ориентированы на достижение детерминированной задержки и согласованных показателей сквозной надежности.
Фактически, 3GPP обеспечивает поддержку как IP, так и не основанных на IP (например, Ethernet, неструктурированных) протоколов на L3 в 5GC. Эти усовершенствования, наряду с потенциальной поддержкой периферийных вычислений, таких как многопользовательские пограничные вычисления (MEC), следует учитывать при оптимизации нового протокола транспортного уровня для удовлетворения экстремальных требований.
9. Удовлетворение экстремальных требований в сценарии мобильности
Обычное переключение каналов (HO) в сценарии мобильности UE включает в себя длительные процедуры и взаимодействия с множеством функциональных объектов как в RAN, так и в CN. Соединение между UE и сетью также прерывается во время HO, когда связь между UE и AP источника прерывается до того, как устанавливается новая линия связи с целевой AP, что нарушает возможность непрерывной передачи и приема данных в любое время. Для случаев использования, таких как AR / VR и мобильного здоровья, где необходимо удовлетворять экстремальным требованиям, даже когда UE является мобильным, необходимы дополнительные усовершенствования в RAN и CN, чтобы не только устранить прерывания, связанные с HO, но также улучшить надежность передачи.
Практической базовой методикой для обеспечения бесшовного и без потерь HO в RAN является процедура Make-Before-Break (MBB – «сделай до перерыва»). В отличие от обычной процедуры HO, которая все время использует одно соединение от UE к сети, MBB позволяет поддерживать соединение с исходной AP даже после того, как UE получает команду HO, чтобы установить соединение с целевой AP. Хотя может быть достигнуто значительное сокращение времени прерывания, для работы в NR RAN в 5G текущий метод MBB все еще не достаточен для удовлетворения требования низкой задержки из-за неспособности UE одновременно обмениваться данными как с исходной, так и с целевой AP.
Чтобы удовлетворить экстремальные требования, крайне важно обеспечить устойчивость к пакетам панели пользователя (UP) во время мобильности, гарантируя, что нет никаких потерь пакетов во время HO. В данном случае использование таких методов, как дублирование пакетов для одних только пакетов UP, не предотвращает сбои и не будет напрямую улучшать устойчивость мобильности. Однако выполнение дублирования пакетов для пакетов как UP, так и пакетов управления (CP), как поддерживается в NR RAN, может повысить общую надежность во время мобильности после разрешения возникновения любых условий отказа. В этом случае, когда одна из ссылок на исходную AP или целевую AP испытывает сбой канала во время HO, все еще могут поддерживаться как RRC, так и соединения для передачи данных.
Процедуры, связанные с управлением мобильностью в базовой сети 5G (5GC), также должны быть согласованы с усовершенствованиями в NR RAN. Процедура смены выходного пути в CN, где требуется функция CP, чтобы изменить путь UP от пути AP-источника к целевой AP, может больше не быть адекватной в свете экстремальных требований. В связи с этим, чтобы гарантировать, что текущий сеанс в CN не прерывается во время мобильности пользователя, 3GPP включил в 5GC три разных режима сеанса и непрерывности обслуживания (SSC), каждый из которых включает в себя различные модификации узла привязки сеанса и возможность маршрутизации трафика. , В частности, режим 3 SSC позволяет поддерживать процедуру MBB в 5GC, где может быть установлено соединение с новой привязкой сессии PDU перед завершением соединения с существующей привязкой сессии PDU. Для обеспечения более высокой надежности может потребоваться усовершенствовать существующую процедуру непрерывности сеанса для поддержки более надежных протоколов транспортного уровня, резервной дорожки и резервных методов выбора UPF.
Дополнительные изменения для поддержки экстремальных требований во время мобильности могут потребовать поддержки со стороны прикладных функций (AF), расположенных как внутри, так и вне области сетевых операторов. Хотя для этого может потребоваться взаимодействие между доменами 3GPP и не-3GPP, осведомленность о внешних по отношению к 5GC возможностях, таких как мобильность AF и периферийные вычисления с множественным доступом, может быть полезна для дальнейшей оптимизации производительности службы на основе E2E.
Целью данной работы являлось определение факторов, которые влияют на надежность и задержку с точки зрения Е2Е, то есть учитывая как 3GPP так и не-3GPP домены, и обеспечить методологию оптимизации разработки сети Е2Е, чтобы минимизировать затраты на развертывание и одновременно обеспечить ожидаемую производительность E2E. В этом контексте задержка и надежность учитывались совместно в разработке методологии, а целью являлась максимизация расстояния сервера приложений от пользовательского оборудования, чтобы минимизировать плотность граничных узлов или обеспечить гибкость развертывания в допустимой области вокруг UE.
Чтобы проверить предложенную методологию, был проведен и предоставлен численный анализ, который принимает в качестве входных данных характеристики радиодоступа, оцененные в Отчете 2.1 данной работы [2], набор требований E2E и набор предположений о частоте отказов узлов и линий и о задержках обработки и передачи. Если входные данные изменились, методология все еще будет пригодной.
Из результатов, полученных из проведенного анализа, можно сделать следующие выводы:
• Экстремальные требования по задержке могут быть выполнены только, если AS размещен на сети оператора.
• Е2Е надежность зависит от надежности UE, RAN, CN и AS.
• Для ряда рабочих точек существует взаимозависимость между надежностью в RAN и надежностью в CN. Если этот диапазон значительный, применяются следующие замечания:
- Целевая надежность RAN может быть снижена за счет улучшения надёжности в CN. И наоборот, целевая надежность CN может быть снижена за счет улучшения надежности RAN. Каждая из них должна быть по меньшей мере такой же как и целевая Е2Е надежность.
- Выбранные целевые надежности будут оказывать влияние на требуемое развертывание цепи.
o Резервирование может использоваться для улучшения надежности и может потребоваться как в RAN, так и в CN.
- Дублирование пакетов может быть использовано в RAN
- Резервные дорожки могут быть конфигурированы в CN
- Резервные дорожки могут быть коррелированы через общую панель управления.
• Так как резервирование может влиять на эффективность энергии и ресурсов, резервирование должно использоваться только тогда, когда требуется.
• Должна быть возможность дезактивировать резервирование в RAN и CN независимо друг от друга.
• Решение по использованию дублирования зависит от целевой надежности в RAN и CN.
• Дублирование может потребоваться как в RAN, так и в CN, либо только в RAN, либо только в CN, либо ни там, ни там.
• Хотя решение по использованию дублирования независимо, решение по включению дублирования в RAN и/или CN не может быть независимым.
• Полное E2E решение, покрывающее RAN и CN, является превалирующим перед сегментированным решением, где по RAN и CN независимо друг от друга принимаются решения по резервированию.
• Е2Е решение по резервированию должно быть способно избежать единственной точки нарушения.
• Новые протоколы транспорта/туннелирования могут использоваться для улучшения надежности без влияния на задержку. Новые протокол должен отвечать требованиям по резервированию в CN.
• Е2Е задержка зависит от задержки в UE, RAN, CN и AS, также как от количества узлов пересылки между точкой доступа RAN и AS.
- Задержки обработки на UE и AS являются не-3GPP задержками.
• Существует взаимозависимость в бюджете задержки между RAN и CN.
- Требования по задержке RAN могут быть ослаблены путем уменьшения целевой задержки в CN. И наоборот, задержка в CN может быть ослаблена путем снижения целевой задержки в RAN.
• Для сервисов с критичной задержкой стоит оценить, есть ли значительная взаимозависимость в бюджете задержки между не-3GPP задержками обработки и 3GPP задержками обработки. В случае, если есть:
- Улучшение возможностей UE и AS за счет снижения задержек обработки может снизить требования к 3GPP задержкам.
- Разработка более простых приложений, которые минимизируют нагрузку требований к 3GPP системе, может снизить требования к 3GPP системе.
- Чтобы удовлетворить экстремальные требования в сценариях мобильности, дублирование пакетов должно поддерживаться во время процедуры переключения каналов.
- Если надежность UE и AS принимается во внимание, может быть необходимо также продублировать функции UE и AS.
- Методы управления неисправностями могут потребоваться на каждом узле. Это включает в себя создание нескольких экземпляров одной и той же функции на разных узлах и дублирование хранилища.
11. Список сокращений
3GPP | 3rd Generation Partnership Project – Партнерский проект 3го поколения |
AL | Access Link – канал доступа |
AP | Access Point – точка доступа |
AS | Application Server – сервер приложений |
CN | Core Network – базовая сеть |
DL | Downlink – нисходящая линия связи |
E2E | End-to-End - сквозной |
eNB | evolved Node B – выделенный узел В |
gNB | generation Node B – генерация узла В |
IP | Internet Protocol – интернет протокол |
LTE | Long Term Evolution – долгосрочная эволюция |
MEC | Multi-access Edge Computing – граничные вычисления с множественным доступом |
MgNB | Master gNB – мастер gNB |
NR | New Radio – Новое радио |
PDCP | Packet Data Convergence Protocol – протокол конвергенции пакетных данных |
QUIC | Quick UDP Internet Connections – быстрые UPD интернет соединения |
RAN | Radio Access Network – сеть радио доступа |
RLF | Radio Link Failure – нарушение радио канала |
RRC | Radio Resource Control – управление радио ресурсами |
SgNB | Secondary gNB – вторичный gNB |
UDP | User Data Protocol – протокол пользовательских данных |
UE | User Equipment – пользовательское оборудование |
UL | Uplink – канал исходящей связи |
URLLC | Ultra-Reliable Low Latency Communication – сверхнадежная связи с низкой задержкой |
TCP | Transport Control Protocol – протокол транспортного контроля |
12. БИБЛИОГРАФИЯ
[I] NGMN, "5G Extreme Requirements: Operators' view on fundamental trade-offS," 28 November 2017.[Online].
[2] NGMN, "5G Extreme Requirements: Radio Access Network Solutions". [3] NGMN, "NGMN 5G White Paper," 2015.
[4] NGMN, "NGMN Perspectives on Vertical Industries and Implications for 5G," 2016.
[5] 3GPP, "Service Requirements for the 5G System," TS 22.261.
[6] 3GPP, "FS_SMARTER - Massive Internet of Things," TR 22.861.
[7] 3GPP, "FS_SMARTER - Critical Communications," TR 22.862.
[8] 3GPP, "FS_SMARTER - enhanced Mobile Broadband," TR 22.863.
[9] ITU, ITU-R M.[IMT-2020.EVAL], 2017.
[10] I TU, ITU-R M.[IMT-2020.TECH PERF REQ], 2017.
[II] 3GPP, New Radio WI, 2017.
[12] 3GPP, LTE URLLC WI, 2017.
[13] 3GPP, "Study on communication for automation in vertical domains (CAV)," TS 22.804.
[14] 3GPP, "Feasibility study on LAN support in 5G," TR 22.821.
[15] 3GPP, "Study on Architecture for Next Generation System," TR 23.799.
[16] A. Hilt, G. Jaro and B. I., "Availability Prediction of Telecommunication Application Servers Deployed on Cloud," Periodica Polytechnics Electrical Engineering and Computer Science, vol. 60, no. 1, pp. 72-81, 2016.
[17] O. Salmela, Reliability Assessment of Telecommunications Equipment, Helsinki University of Technology , 2005.
[18] [Online]. Available: https://ece.uwaterloo.ca/~ece477/Lectures/ece477_3.ppt.
[19] "Fibre optic: What are achievable distances with single-mode and multi-mode fibre," [Online]. Available: https://www.universalnetworks.co.uk/faq/fibre-optic/what-are-achievable-distances-single-mode-vs-multi-mode-fibre.
[20] K. Papagiannaki and e. al., "Measurement and Analysis of Single-Hop Delay on an IP Backbone Network," IEEE Journal on Selected Areas of Communications, vol. 21, no. 6, 2003.
[21] N. Zilberman, M. Grosvenor, D. A. Popescu, N. Manihatty-Bojan, G. Antichi, M. Wojcik and A. W. Moore, 'Where Has My Time Gone?," in International Conference on Passive and Active Network Measurement, 2017.
[22] "Transport Layer Security (TLS)," [Online]. Available: https://hpbn.co/transport-layer-security-tls.
[23] Huawei, "Evaluation on Packet Duplication in Multi-connectivity," in 3GPP WG2 R2-1700172, 2017.
[24] J. Rao and S. Vrzic, "Packet Duplication for URLLC in 5G: Architectural Enhancements and Performance Analysis," IEEE Network, vol. 32, no. 2, pp. 32-40, 2018.
[25] 3GPP SA WG2, "New SID: Study on enhancement of URLLC supporting in 5GC," SP-180118, 2018.
[26] 3GPP SA WG2, "Study on enhancement of URLLC supporting in 5GC," TR 23.725, 2018.
[27] "R2-1805449 (MCG RLF handling in case of NE-DC (TP to 37.340))".
[28] Q. De Coninck and O. Bonaventure, "Multipath QUIC: Design and Evaluation," in In Proceedings of the 13th International Conference on emerging Networking Experiments and Technologies (CoNEXT '17), ACM, Incheon, Republic of Korea, 2017.
[29] 3GPP, "Feasibility study for further advancements for E-UTRA (LTE-Advanced)," TR 36.912.
[30] I TU-R M.2135, "Guidelines for evaluation of radio interface technologies for IMT-Advanced," 2008.
[31] N. A. Johansson, E. Y.-P. Wang, E. Eriksson and M. Hessler, "Radio Access for Ultra-Reliable and Low-Latency 5G Communications," in IEEE ICC - Workshop on 5G & Beyond - Enabling Technologies and Applications, 2015.
[32] 3GPP, "Study on scenarios and requirements for next generation access technologies," TR. 38.913.
[33] 3GPP, "Study on new radio access technology Physical layer aspects," TR 38.802.
[34] S. Parkvall, E. Dahlman, A. Furuskar and M. Frenne, "NR: The New 5G Radio Access Technology," IEEE Communications Standards Magazine, 2017.
