В общем-то имел опыт работы с несколькими типами OFDM сигналов и думал, что понимаю всё - от и до. Однако столкнулся тут с проблемой и понял, что мне не приходит в голову решения.

Имя этой проблеме Mobile WiMAX, т.е. IEEE 802.16-2009 глава 8.4 - OFDMA. А именно обнаружение и синхронизация с базовой станцией. Для тех, кто не в курсе, вкратце расскажу. Все базовые станции (БС) сети одного оператора синхронизированны между собой, то есть в один и тот же момент каждые 5 милисекунд начинают посылать фрейм. Чтобы БС, работающие на одной частоте, друг с другом меньше интерферировали каждая базовая станция имеет свой паттерн перестасовки поднесущих, отличный от паттернов соседних БС, но не уникальный. Всего таких паттернов 114, или по 38 в каждом из трёх (условных) секторов БС. Условных потому, что нигде не прописано, что БС должна иметь сектора и если должна, то сколько. Но условно паттерны разделяются на три сектора. Чтобы в момент приёма понять, что за паттерн используется данной БС, а также в целях синхронизации с БС, фрейм предваряется преамбулой, которая является почти таким же OFDM-символом с циклическим префиксом как и все другие символы фрейма. Только преамбул этих 114 видов (по количеству паттернов). Имеют они не хитрую структуру: в них присутсвует энергия в каждой третей поднесущей, а все остальные поднесущие пусты. Как не трудно догадаться, установить каждую третию поднесующую можно тремя способами. Соответственно, который из этих способов используется данной БС, тот и определяет её условный сектор - 0, 1 или 2. А дальше, как было сказанно выше, каждый сектор имеет 38 уникальных преамбул. Они по сути являются псевдослучайными последовательностями единичек и ноликов, которые модулируют не пустые поднесущие созвездием BPSK. Все эти 114 последовательностей прописаны в стандарте.

Так например, положим у нас есть преамбула 11001001..... в нулевом секторе. Тогда поднесущие 0, 3, 12 и 21 будут иметь фазу 0, а поднесущие 6, 9, 15 и 18 - фазу Pi, и некоторую не нулевую и одинаковую амплитуду, а остальные поднесущие имеют амплитуду 0.

Соответственно, на приемной стороне требуется.
1) Обнаружить и найти преамбулу
2) Найти центральную частоту
3) Определить тип преамбулы, а точнее сектор и номер внутри сектора.

Не выполнив третий пункт можно синхронизироваться, но демодулировать фреймы невозможно, так как из номера преамбулы и номера сектора вырабатывается туева хуча перестановок поднесущих. То есть все три пунтка обязательны.

Вот тут и возникает задница. До селе я использовал следующий алгоритм.

1) Находил автокорреляцией циклический префикс. Но у него очень размазанный корреляционный пик. Поэтому, так можно определить только лишь примерное место, где имеется OFDM-символ. Понять преамбула это или нет также не представляется возможным. Однако, результат этих вычислений можно использовать для оценки частотного смещения. Причем оценить смещение по частоте таким способом можно лишь в пределах +/- 0.5 шага между поднесущими.

2) Сигнал любой из 114 преамбул, из-за того, что в нем фазы всех поднесущих отличаются на 0 или Pi (то как бы есть лежат на одном диаметре окружности) должен быть симметричен во времени относительно центральной точки, делящей преамбулу пополам. Соответственно, если мы успешно проверили гипотезу в первом шаге, то проверяем гипотезу симметричности во времени. Если она выполняется, значит мы локализовали преамбулу (или что-то очень на неё похожее) с точностью до одного сэмла и переходим к следующему шагу.

3) Делаем преобразование Фурье, смотрим в каком из трёх возможных распределений поднесущих содержится максимальная энергия, и пытаемся демодулировать эти поднесущие. Исходя из того, что мы не можем локализовать преамбулу с точностью большей чем один сэмпл, получается, что фазы поднесущих уже могут не быть строго 0 и Pi, но разность фаз между соседними поднесущими не должна сильно отличаться от 0 и Pi. Поэтому проходим все поднесущие слева на права и демодулируем каждую поднесущую как бы относительно предыдущей. Резонно, что мы не знаем как была модулирована первая поднесущая. Поэтому мы получаем две инвертированных относительно друг друга последовательности нулей и единиц. А далее находим наименее отличающуюся эталонную (одну из 114) последовательность по таблице из стандарта.

Всё хорошо, но вот сигнал, записанный на узкой улочке, не проходит через этот алгоритм. Модем провайдера при этом ухитряется работать - плохо, но работает. А мой алгоритм не проходит проверку второй гипотезы ни в одной точке. Хотя если там искусственно загрубить порог правдоподобия, т.е. сразу перейти к шагу 3, то там хорошо видно, что энергия сигнала распределена по каждой третьей поднесущей, то есть там преамбула. Однака попытка её демодулировать кончается тем, что ближайшая по похожести преамбула определяется с очень большим количеством несовпадений и, как видно в дальнейшей работе, определяется к томуже не правильно. То есть получается, что поднесущие присутствуют правильные, но у них что-то не так с фазами.

Что я здесь не учел? Похоже, что многолучевость. Ведь поднесущие, фазы которых лежат на одном диаметре (как было описано выше) на передаче, в результате действия многолучевости, совершенно не обязательно будут иметь (примерно) фазы такой же структуры на приёме. А тогда, если фазы не лежат на одном диамете, сигнал во временной области теряет своё свойство симметрии. А биты (даже если мы случайно попадем точно в преамбулу) тем более не понятно как тогда демодулировать. Оценить канал и построить эквалайзер на данном этапе просто не по чему. Что же делать и как выяснить номер преамбулы в таком случае?

До сих пор встречались лишь OFDM-сигналы, в которых преамбула всегда одна и таже. В таких сигналах я обнаружал её в частотной области и по ней уже строил эквалайзер. То есть задачи определить её конкретный вид, основываясь на фазах поднесущих, не стояло.

Скорее всего - да. ИХ канала наверняка слишком длинная, чтобы такие примитивные алгоритмы синхронизации, рассчитанные на один луч, работали.

Почему не хотите попытаться найти кросскорреляцию с каждой из возможных 38 синхропоследовательностей? И из неё получить ИХ канала?

В селективном канале и амплитуда на отдельных частотах преамбулы будет разной, не только фаза. Но фаза должна скакать гораздо неожиданнее. Поэтому по ним нужно обучать частотный эквалайзер.

Для этого надо хотя бы знать центральную частоту. В стандарте WiMAX нет частотного плана, увы. Поэтому в общем случаее приходится производить поиск абстрактного ваймакса в вакууме. Не с шагом в 1 Гц же его искать.

Кроме того, не совсем вас понял, как можно из кросскорреляции получить ИХ канала? В смысле найти максимальную из 38 и относительное неё построить ИХ канала? Это можно попытаться сделать (опять же, если знать центральную), но надо понимать, что с такой преамбулой можно построить только ИХ 1/3 канала.

Так как автокореляция последовательности там скорее всего узкий пик, то кросскорреляция и есть ИХ канала. Разная на разных частотах. НО полную длину оценить наверное можно. Кстати, в ваймаксе какова длина циклического префикса?

Да, промерить можно только треть частот. Значит, скорее всего нужно интерполировать частотный эквалайзер на промежуточные частоты. А какие еще есть варианты?

Да, всё что я пишу может быть бредом, так как с ваймаксом дела не имел и его тонкостей не знаю

Длина циклического префикса согласно стандарта может варьироваться: 1/32, 1/16, 1/8 и 1/4 от длины символа. Однако производители оборудования решили поддерживать только 1/8. То есть для 1024 точек FFT - это 128 сэмплов.

А вот в начало вашей фразы я не совсем врубился. О каком "узком пике" и о какой "полной длине" идёт речь?

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

Кто вам сказал, что символ преамбулы состоит из двух одинаковых половинок? Это возможно только если в преамбуле присутствуют только чётные или только нечётные поднесущие, как, например, в WiFi. Если вы читали внимательно, то в преамбуле OFDMA присутствует каждая третья поднесущая. Это автоматически означает, что это не будет работать. Возможно, он подходит для Fixed WiMAX, но речь сейчас о Mobile WiMAX.

Какова частота сэмплирования при этом?

Узкий пик автокорреляционной функции преамбулы проистекает из её вероятной псевдослучайности.

"Полная длина" - это длина существенной части ИХ канала. В которую собраны наиболее существенные лучи.

Да действительно...

В ваймаксе символ преамбулы во времени из 3-х повторяющихся частей состоит:

http://202.194.20.8/proc/MILCOM08/Milcom08/pdfs/1272.pdf

С учётом этого можно сделать алгоритм синхронизации подобный алгоритму Schmidl-а.

Она ни разу не псевдослучайна. В OFDM не бывает псевдослучайных функций во временной области, именно поэтому синхронизация в OFDM - это настоящий геморрой. А если учесть, что есть циклический префикс, то этот "пик" превращается в "плато" длинной 128 точек и очень пологим склоном.


Ага, из трёх. Осталось поделить 1024 на три равных части...

Читал я этих "деятелей науки". Преамбула состоит из трёх повторяющихся частей, только если её дискретизировать на тройной скорости, что, скажу я Вам, не проще, чем женской писькой улыбаться. Одинарная скорость 11.2 МГц. Мне кажется, что та писюлька, которая используется в качестве модема у йоты и комстара не может обработать поток 33.6 МГц, а значит она точно не использует это "алгоритм". А на одинарной скорости там получается три "как бы" похожих друг на друга куска, так как 1024 точки на три на цело не делится, и коррелируют эти кусочки даже на идеальном сигнале весьма условно.

В общем реализовывал я этот алгоритм, когда начинал я этим заниматься. Вывод: ребята неплохо освоили грант. За пару ночей, наверное.

И наконец, даже если хитро извернуться и реализовать синхронизацию таким вот способом, то это не решает проблему идентификации типа преамбулы.

Да соотношение неудачное в стандарте выбрали. Заказные чипы и не на таких скоростях работать могут и при малом потреблении. Сигнал обладает определёнными автокорреляционными свойствами это можно и нужно использовать, уверен что в реальных модемах модификация Schmidl-а под этот сигнал используется.





Почему?

Потому что Schmidl & Cox дает ответ в виде "преамбула есть и она вот здесь". Он не дает ответ на ворос о том, какая это из 114 преамбул. Не говоря уже о том, что оперелить частотное смещение более чем на +/- 0,5 растояния между поднесущими здесь тоже не судьба. А очень надо, потому как хочется сканировать эфир бОльшими шагами по частоте.




Я думаю, что когда придумывают стандарт, то сначала обкатывают идею и убеждаются в том, что у неё есть эффективное решение. Думали они, наверное, и в этом случае, только проблема в том, что эти мысли не попадают в стандарт.


Понимаете в чём дело? Синхронизация и поиск - это безусловно очень важный этап, но сделав его один раз при включении, больше этим заниматься не надо, только подсинхронизироваться, но это уже в порядки меньше вычислений. И кроме как на этом этапе обработка сигнала с утроеной дискретизацией больше нигде не нужна. Я не верю, что ради этого требуется усложнять чип настолько, что его площадь раза в два увеличится. И, наверняка, об этом же думали, когда писали стандарт.

Разумеется помимо обнаружения начала пакета нужно ещё кучу всего сделать, канал оценить по нескольким последующим символам и компенсировать, точнее подстроить синхронизации, только после этого можно определять какая из 114 преамбул передавалась, преамбулы по какому-то закону генерируются, это тоже наверняка как-то можно использовать чтобы все не перебирать. Про сканирование большими шагами не понял, разве в стандарте нет фиксированной сетки частот?






Что-то должно быть в статьях IEEE и патентах.




Почему же только при включении? С каждым новым пакетом заново синхронизироваться нужно будет. Нормально это что для пакетной связи на начальном этапе больше вычислений требуется. Вряд ли в 2 раза, больше всякие декодеры помехоустойчивых кодов займут и т. п.

Нет.


Это не пакетная система. Демодулировав заголовок одного фрейма, в общем случае можно узнать как часто идут фреймы: БС шлёт их периодично. На практике и это не нужно, так как на сей день используется только значение 5 милисек. То есть нашел, где одна преамбула, через 5 милисек там же будет и другая. Конечно, она уплывает из-за того что генераторы разные, но не более чем на +/- 1 отсчёт за несколько фреймов - тут уже проще. И определять, что за базовки рядом тоже не надо, т.к. о них уже рассказывается в служебных сообщениях с указанием центральных частот, номеров секторов и индекса используемой преамбулы.

ИМХО эта статья как раз указывает, как избежать тройной скорости (3х). Для того, чтобы 3 части преамбулы были максимально похожи (не 100%, но близко) на скорости 1х, надо их обрабатывать (коррелировать) с задержкой или ускорением на 1/3 дискрета. Вы это пробовали?

Конечно, поиск несущей придется вести во всем диапазоне, соответственно входной блок должен быть широкополосным (3х). Затем можно перестраиваемым полосовым фильтром сужать рабочую полосу, децимировать и коррелировать уже на 1х. Та несущая, на которой коррелятор даст пик выше порога, автоматически идентифицирует БС или даже БС-сектор.

Сам я с OFDMA не работал, могу и ошибаться, но судя по статье выше и WiMAX from Wikipedia, расширение диапазона - это плата за многопользовательский доступ, гибкую поддержку разнообразных частотных планов и относительно сильную защиту от многолучевости в одном "букете". Похоже, обработка преамбулы - основное отличие OFDMA от OFDM. Если же всю обработку вести на 1х, то теряем чувствительность на этапе синхронизации со всеми вытекающими.