Комментарии 5
Отличная статья
Но есть проблема: таких устройств много. Если все они будут потреблять трафик на полной скорости без ограничений, мы быстро упремся в пропускную способность gNB. .
Нехватка пропускной способности проявляется не только при большом количестве UE, но и при снижении качества связи (росте числа ошибок). В сетях LTE это видно очень хорошо, я думаю в 5G это проявится еще сильнее. При передаче пакетных данных с использованием протокола TCP (протокол гарантированной доставки) в канале с большим уровнем ошибок происходит: 1) многократная повторная передача, что занимает канал, но снижает полезную скорость и 2) переход на способ модуляции с меньшей скоростью передачи. Я фиксировал на телефоне в сети LTE скорость 200 Мбит/с в точке с хорошим покрытием и 100 кбит/с при слабом сигнале (измерения проводились, естественно, в часы наименьшей нагрузки). Самый дорогой способ повышения скорости - улучшение покрытия. Гораздо менее затратный - введение специального помехоустойчивого кодирования, которое может увеличить скорость полезной передачи в 20 раз, устранить повторную передачу пакетов и переход на низкоскоростные методы модуляции и снизить занятость каналов.
Спасибо за интересную статью.
Правильно ли я понимаю, что динамическое изменение GBR через SMF является policy-driven механизмом, при котором SMF устанавливает QoS-параметры, а их фактическое соблюдение в конечном итоге зависит от scheduler’а в RAN (gNodeB)?
Корректно ли в этом случае рассматривать такие изменения как «инициированные со стороны Core», без жёсткой гарантии на уровне радиодоступа, или в вашей архитектуре предусмотрены механизмы обратной связи и согласования между RAN и Core?
И как в реальных deployment’ах решается вопрос согласованности между PCC-политиками (Core) и фактическим распределением радиоресурсов (RAN), особенно в условиях перегрузки?
в вашей архитектуре предусмотрены механизмы обратной связи и согласования между RAN и Core?
Да, есть механизм обратной связи. SMF при изменении QoS характеристик отправляет запрос в gNB на выделение ресурсов, который она вправе удовлетворить или отклонить в зависимости от имеющихся ресурсов. Также она может отправить нотификацию в SMF о том, что какие-то QoS Flow были удалены в связи с нехваткой ресурсов. Дальше - дело опорной сети, как из этой ситуации выходить.
И как в реальных deployment’ах решается вопрос согласованности между PCC-политиками (Core) и фактическим распределением радиоресурсов (RAN), особенно в условиях перегрузки?
Изначально, когда оператор занимается планированием мобильной сети, он рассчитывает свои услуги, исходя из целевого количества абонентов, имеющихся ресурсов и характеристик базовых станции. В условиях перегрузки, например, когда в Новый Год сразу много абонентов хотят позвонить, какие-то звонки просто не устанавливаются или дропаются уже установленные, чтобы обеспечивать ротацию ресурсов. Если такая перегрузка не временная, а постоянная, оператор это видит на своих панелях управления сетью, и может предпринять какие-то шаги для решения этой проблемы (подрезать услуги, увеличить количество базовых станции и т.п.).
Чисто с обывательской т.з. - полезно. Дополнительный артефакт, чтобы сношать мозги ОпСоСам...
И про тариикацию траффика - оч. любопытно. Те же ОпСоСы недавно жаловались что такое невозможно и вжух... Все врут (с)...
Policy and Charging Control: зачем классифицировать трафик в сотовой сети и как это сделать