В общем-то имел опыт работы с несколькими типами 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х, то теряем чувствительность на этапе синхронизации со всеми вытекающими.

Мне проще было не задерживать на 1/3 дискрета, а децимировать в 3 раза реже. Пробовал. Так работает. Но о реал-тайме тут говорить тяжело.


Основное отличие OFDM от OFDMA - это то, что в последнем одновременно могут излучать несколько источников, каждый используя свой набор поднесущих.

Без задержки на часть дискрета децимация в 3 раза даст периодически затухающий корреляционный пик 2-й и 3-й частей преамбулы. Задержка на 1/3 дискрета - это я условно обозначил. На самом деле, задержка накапливается долями по 1/3 дискрета после каждого последуюшего символа. Для этого необязательно задерживать принятый сигнал, можно и местную реплику, что несложно сделать на fixed point DSP, как это делают GPS приемники - там частота постоянно ползет из-за быстро меняющегося доплера.


А эти несколько источников приемник как будeт различать? Не по результату ли синхронизации с преамбулой?

Надо, наверное, пояснить. Структура фрейма WiMAX делится на две части: downlink и uplink. В downlink'е излучает только базовая станция, и приёмникам различать ничего не надо. В uplink'е излучают только абоненты. На каких поднесущих и в какое время им излучать, сообщается базовой станцией, которая и является приёмником их сигнала. Её же задачей является распределение поднесущих между абонентами так, чтобы они не пересекались. Таким образом, приемнику надо просто знать "что", "где" и "когда". Здесь нет такого как в GPS, что спутники передают на одной и той же частоте используя для разделения разные ПСП. Здесь всё достигается ортогональностью.

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

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

Во-первых, у оператора есть несколько частот, как правило. Во-вторых, если несколько БС, работающих на одной частоте, попадают в зону видимости одного абонента, то им (БС) назначают разные сектора, тогда их преамбулы будут друг другу ортогональны и абонент может выбрать себе ту, у которой больше CINR. Дальнейшее разделение происходит уже за счёт превышения сигнала одной БС над сигналами других, а также на помощь приходит грамотное перетасовывание частот и турбокод. Понятно, что в точке, где несколько БС слышно одинаково хорошо (или одинаково плохо) ни о какой разумной работе речь идти не может. Поэтому тут должен использоваться уже другой частотный канал.

В общем речь в данном посте шла совсем не об особенностях развёртывания сетей WiMAX, а о конкретном алгоритме, так что хватить оффтопить.

Если еще актуально.
Быстрый поиск точного начала преамбулы для OFDMA подробно описан в статье

"A new method for frame synchronization in OFDMA mode of WMAN"



Ссылку на нее можно найти в ветке форума

"Если у кого есть халявный доступ к материалам IEEE, помогите скачать статейку плз."


Используется свойство комплексно сопряженной симметричности преамбулы во временной области.
Дает очень яркие пики. Устойчив к неопределенности по частоте несущей.
Возможен вариант поиска при неизвестной длине циклической приставки.

Номер (один из 114) определяется вычислениями в частотной области.
Если интересна процедура определения номера преамбулы без знания частоты несущей - могу написать.

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

Что скажете на это, уважаемый?

Да... сложная ситуация.
А можно выложить куда-нибудь реализацию радиосигнала (несколько пакетов Downlink)?
Интересно взглянуть на "дикий" сигнал.

DMax, спасибо за ответ в ветке по STC.

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

Правда вот не знаю как дать числовую характеристику "дикости" моих сигналов .

Да и когда базы других сегментов начинают влиять - тоже некрасивая ситуация.

Единственное что приходит в голову - может дело в приемной части?

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

chturm-88@mail.ru