PAPR для SC-FDMA Опции

[infinity]

Требуется сделать модем с низким PAPR.
В ходе рассмотрения возможных вариантов реализации физики обратил внимание на sc-fdma.
Насколько я понимаю, из стандартов, использующих эту физику есть только lte.

По результатам моделирования оказалось, что значительное уменьшение PAPR происходит только при уменьшении количества активных поднесущих. Например, при общем количестве поднесущих = 1024 и активных 256 получим снижение PAPR с 12 до 6 Дб для расстановки поднесущих по ifdma.

Терять пропусную способность не хочется. Что же делать? Обратившись к стандарту lte увидим странную штуку:
sc-fdma используется в восходящем канале с максимальным индексом модуляции qam16. т.е. при максимальной полосе 20MHz получаем 80Mb/s, вычтем потери на синхронизацию, управление сетью, кодирование и др. избыточность. Останется что-то в районе 50-60 Mb/s чистой пропускной способности на пользовательский трафик. И эту же скорость заявляют как доступную для пользователя, но ведь в этом случае будут использоваться все поднесущие. Следовательно PAPR будет в районе 12дБ. А основной плюс sc-fdma - низкий papr. В чем же дело?

Есть фантастическое предположение, что поднесущих нужно расставлять хитрым образом, тогда и par снизится и все поднесущие можно будет задействовать, только как?

Гуру, объясните, как же получается низкий papr без потери пропускной способности?

[EvgenyV]

Не гуру, но кое-какие сумбурные мысли по этому поводу есть.

Мегаскорости 60-80Мб/с это теоретически максимально допустимые скорости в сферическом вакууме, о чем и трезвонят PR отделы. На практике стоит делить все раза в 2-3-4-.... Такие скорости достижимы (опять же в теории) если на одного юзера выделить все 20МГц спектра. Тогда papr действительно будет большим (12 дб). В LTE uplink на самом деле в один момент времени весь спектр в 20МГц делиться scheduler'ом на несколько юзеров. Параллельно вещает сразу несколько передатчиков, они все засинхронизированны по времени. Тогда количество поднесущих у одного юзера уменьшается, соответсвенно и уменьшается у него papr. Получается, что поток данных в еденицу времени в канале, скажем, 50Mbs и ширина спектра 20Мгц, но исходящий трафик от одного юзера гораздо меньше - 1/N.

Поправьте, если ошибаюсь.

[infinity]

Не гуру, но кое-какие сумбурные мысли по этому поводу есть.

Мегаскорости 60-80Мб/с это теоретически максимально допустимые скорости в сферическом вакууме, о чем и трезвонят PR отделы. На практике стоит делить все раза в 2-3-4-.... Такие скорости достижимы (опять же в теории) если на одного юзера выделить все 20МГц спектра. Тогда papr действительно будет большим (12 дб). В LTE uplink на самом деле в один момент времени весь спектр в 20МГц делиться scheduler'ом на несколько юзеров. Параллельно вещает сразу несколько передатчиков, они все засинхронизированны по времени. Тогда количество поднесущих у одного юзера уменьшается, соответсвенно и уменьшается у него papr. Получается, что поток данных в еденицу времени в канале, скажем, 50Mbs и ширина спектра 20Мгц, но исходящий трафик от одного юзера гораздо меньше - 1/N.

Поправьте, если ошибаюсь.

Все это конечно красиво звучит, и такие мысли в воздухе роятся, только верить в них не хочется. Да и в стандарте нигде не встречал упоминания о том, что база дает ограничение на количество поднесущих одному юзеру. Опять же, lte позиционируют как большие абонентские скорости и маленькие задержки передачи трафика

Используем все поднесущие, соответственно FFT и IFFT выкидываем, получается обычная модуляция с одной несущей без сглаживания с минимальным PAPR.
Если у вас FDMA нету то все эти LTEшные заморочки не нужны.

Звучит красиво, вот только слишком много если: и синхронизация нужна практически мгновенная частотная и временная, да и ару с гестерезисом не приветствуется. Плюс очень хочется данные размазать по времени и частотам. А всё это на классике осилить тяжело. Пока что в качестве решения видиться только использование базиса (например fft) с пакетной передачей.

Да и про одну несущую вы немного не договариваете, на bpsk papr=6Дб возможно и увидим, но переходя на более высокие индексы модуляции увидим увеличение papr. А способы уменьшения всё те же, что и для ofdm'a. На настоящий момент не один из них меня не устраивает.

[EvgenyV]

Да и в стандарте нигде не встречал упоминания о том, что база дает ограничение на количество поднесущих одному юзеру.

В uplink'е есть PUSCH канал, который так и называется Physical Uplink SHARED Channel. Он и делится между юзерами. Это 100%!
Я пару лет назад физический уровень LTE-Uplink на FPGA делал. Как раз SC-FDMA модуляцию. Я картинку прикрепил. По горизонтальной оси частота, вся область занятая квадратами и будет 20МГц. По вертикали - время. Там sub-frame это один SC-FDMA символ.

Звучит красиво, вот только слишком много если: и синхронизация нужна практически мгновенная частотная и временная, да и ару с гестерезисом не приветствуется.

Насчет синхронизации. Насколько помнится, юзер (UE -User Equipment) сначала вступает в сеть, синхронизируется с базой (eNodeB) и так и находится в синхронизированном состоянии (по времени). Вообще все UE, подключенные к одной eNB засинхронизированны по времени между собой. У каждого UE свой schedule того, когда надо передавать данные и на каких поднесущих. Поэтому когда одновременно вещают несколько UE каждый в своем диапазоне частот внутри этих 20МГц, не происходит коллизий и МСИ. Там какая-то мудрая система scheduling'а.

[infinity]

В uplink'е есть PUSCH канал, который так и называется Physical Uplink SHARED Channel. Он и делится между юзерами. Это 100%!
Я пару лет назад физический уровень LTE-Uplink на FPGA делал. Как раз SC-FDMA модуляцию. Я картинку прикрепил. По горизонтальной оси частота, вся область занятая квадратами и будет 20МГц. По вертикали - время. Там sub-frame это один SC-FDMA символ.

Честно говоря, картинка все еще больше запутала. Попробую перефразировать свой вопрос. Низкий papr -это как минимум поделитить все поднесущие на 4 абонентов, например так:



В lte утверждается, что papr низкий. Значит ли это, что один абонент не может запросить на передачу трафика больше 1/4 от общего количества поднесущих?

[EvgenyV]

Согласен, картинка запутанная. Я сам в нее долго вникал. Извиняюсь. Всего лишь хотел показать, что канал делится между абонентами.

Значит ли это, что один абонент не может запросить на передачу трафика больше 1/4 от общего количества поднесущих?

Теоретически абонент может запросить больше чем 1/4. По-крайней мере в настройках передатчика, который я делал, можно было выделить все поднесущие на одного юзера. Как на практике распределяются ресурсы, я увы не знаю. Это где-то на более высоком уровне делается, не на физическом. Я в этом не разбирался. Возни и без этого хватало )

Возможно вы правы, что низкий papr и достигается тем, что юзеру не дают более чем 1/4 ресурсов за раз.

[petrov]

Возможно вы правы, что низкий papr и достигается тем, что юзеру не дают более чем 1/4 ресурсов за раз.

Низкий PAPR достигается когда юзерам выделяются поднесущие как на рисунке а), хоть одну поднесущую хоть все, PAPR будет одинаково низким.

[EvgenyV]

Низкий PAPR достигается когда юзерам выделяются поднесущие как на рисунке а), хоть одну поднесущую хоть все, PAPR будет одинаково низким.

Хмм. Действительно так. Похоже я заблуждался :)
Посимулировал в Матлабе. PAPR не сильно меняется от количества несущих.
У меня также получилось, что и при а), и при b) PAPR не сильно отличается.

Вот моя симуляция. Делал по памяти, может где ошибся. Поправьте если что.

CODE

close all;
N = 120; % number of carriers
K = 1; %
S = 0; % start
h = modem.qammod(16); % create an object with default properties
x = randint(N, 1, 16); % generate input bits
y = modulate(h, x); % modulate x
% scatterplot(y)

buf1 = zeros(1536, 1);
buf1(169+S:168+S+N) = y; % subcarrier mapping
plot(abs(buf1));
dftout = fft(y);
plot(abs(dftout));

buf = zeros(4096, 1);
buf(1281+S:K:1280+S+N*K) = dftout; % subcarrier mapping
figure; plot(abs(buf));

sc_fdma = ifft(buf);
figure; plot(abs(sc_fdma));

papr = 20*log10(max(abs(sc_fdma))/mean(abs(sc_fdma)))

[petrov]

Чтобы PAPR считать нужно квадрат модуля брать а не просто модуль, ну и статистика нужна, одна реализация случайных данных может сама по себе низкий PAPR иметь.