Приветствую всех!

Кто-нибудь знает WiMAX решения на ПЛИС или DSP? "Краем глаза" читал про платы на чипах Fujitsu, Wavecom... Может есть другие решения? Программы прошивки ПЛИС или для DSP?
Считаем поставленной задачу после процесса АЦП и до выдачи информационного сигнала и наборот до процесса ЦАП.

думаю что и по стоимости (разработка + итоговый bom) и по ТТХ (потреблению и габаритам), будет намного разумнее искать готовые решения..

другое дело ,что простому смертному разработчику они практически недоступны (TI, Marvell, etc).. но это уже другая история..

посмотрите на Xilinx web site. Там они раздают ref.design, сделаный на sysgen. По моему до 6 каналов UP and DOWN. Может больше. Pretty impressive.

Почти каждый производитель FPGA/DSP имеет в своем разпоряжении более или менее законченное решение для Wimax
TI: C64 DSP + TataElxsi MAC/PHY software stack
Freescale: DSP + network processor + sw
PicoChip: оригинальное решение
Intel

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

Спасибо всем за ответы. Буду разбираться. Как показала практика - готовое решение не всегда готовое на 100%. Вот и хочется получить ПЛИС/DSP в которой бы сидел этот самый WiMAX на все полосы от 0,75МГц до 28МГц и все скорости. Как стационарный, так и мобильный. А то каждая фирма предлагает свой частный случай...

Делали подобное решение - PHY уровень на ПЛИС, MAC и Management уровень на ARMе. А что Вас конкретно интересует?

Такое маловероятно, по маркетинговым причинам. WiMAX форум выбрал честь из того, что описано в 802.16 (+e) и это назвал Wimax. Так что все пытаются слелать, то что утвердил WiMAX форум (что можно продать). А там помойму не все возможные полосы и не все скорости. Так же пока обычно идет разделение на мобильный и стационарный (там нет полосы 28МГц)


Вы не могли бы посоветовать хороше описание MAC уровня (кроме стандарта самого по себе), с прицелом на имелементацию? Может есть какие-то opensource исходники Wimax MAC?
Я нашел две книжки, но там как мне кажется описаны не все нюансы
Loutfi Nuaymi WiMAX Technology for Broadband Wireless Access и
Fundamentals-of-wimax-understanding-broadband-wireless-networking

А какие нюансы? На каждый CID существует своя очередь, в которую приходящие из сети пакеты попадают согласно классификаторам CIDа. Раз на фрейм вызывается функция планировщика, которая "набивает" фрейм целыми либо кусками этих пакетов, согласно параметрам QoS и свойствам очереди (пакетированная и/или фрагментированная).
Похоже на задачу укладки предметов в рюкзак, только сложнее, поскольку надо учитывать физические параметры burst-ов и множество разных ограничений.
Также необходимо анализировать приходящие запросы на передачу данных от АС.
Еще существует ряд управляющих MAC сообщений, которые предназначены для процедуры вхождения в сеть, переодического апдейта физических параметров и организации сервисных потоков и криптографических ассоциаций.
Они тоже кладутся в очереди по Basic или Primary Management CID для планировщика. Вырабатываются они по графам состояний, описанным в стандарте.

Еще есть более-менее внятные книги

WiMAX Handbook Frank Ohrtman
WiMAX Applications Syed Ahson Mohammad Ilyas
WiMAX/MobileFI Yang Xiao
WiMAX Standards and Security Syed Ahson Mohammad Ilyas
WiMAX Technologies Performance Analysis and QoS Syed Ahson Mohammad Ilyas
Mobile WiMAX - Toward Broadband Wireless Metropolitan Area Networks Yan Zhang Hsiao-Hwa Chen

Правда, вопросами реализации нигде не уделяется много внимания...

Где бы эти книги как бы ну это самое?
Вдруг там есть то что мне надо...

А есть такие книги, где описывается, как программно реализовать физический уровень mobile wimax? Я такую только одну встречал, но она оказалась пустышкой...

Ведь те кто разрабатывает чипы для 802.16e не роботы и не могут опираться на один лишь только стандарт... По крайней мере я в это не верю, что они по стандарту что-то смогли сделать, это бред...

То есть как это - "программно реализовать физический уровень"???
Что, программой уже можно заменить Transceiver?

Пожалуйста, не надо так реагировать Я понял что Вас смутило, но могу обрадовать, что физический уровень WiMax из одного только радиотракта не состоит и все-таки после АЦП там что-то есть О чем, кстати, стандарт и повествует, уделяя лишь немного внимания тому что идет между антенной и АЦП/ЦАП.

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

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

Кто разрабатывает чипы они стандарт и пишут, это разработки очень высокого уровня с соответствующими исследованиями.

Смешно, конечно, но по видимому так и есть. По крайней мере я уже не одну неделю пытаюсь сделать математическую модель коррелятора для преамбулы WiMax. Определенные результаты уже получил, но реализация их в ПЛИС будет занимать до хрена ресурсов. Я не верю, что разработчики стандарта исходили из того алгоритма, что придумал я, так как сделать дешевое устройство с такой большой плиской не реально. А стандарты ведь создаются с учетом того, чтобы технология пошла в массы.

Вот, например, Mobile Wimax определяет 114 преамбул. И они явно сформированы не случайным образом, однако никакого описания того, как их формировали, в общем доступе нет. А ведь наверняка, используя это свойство, можно построить коррелятор в разы оптимальней чем мой...

Поэтому склоняюсь к тому, что они там собрались на WiMax форуме и написали филькину граммоту, и назвали её 802.16, а сами пользуются тайным знанием....

Нет тут никакой черной магии и белой тоже нет.

Wimax forum не писал 802.16, а писал его IEEE комитет. Форум только брал оттуда куски и составлял "профайлы" о том, что называть wimax и как это пользовать.
Насколько я знаю (а мой опыт восновном больше по MAC уровню) все делают в лоб по стандарту. Волшебной книги с рекомендациями как делать правильно не существует в природе. Причина ее отсутствия в том, что стандарт существенно меняется и написаная книга тут же устаревает. Хотя может, когда все всё сделают, поделят рынок и будут переходить на новый стандарт, то появится такая книга с исчерпывающим описанием великого прошлого.
Теория OFDM(A) связи разработана в 50-х годах прошлого века. PHY Wimax-а ничего вобщем-то не изобретает а делает как по учебнику отличаясь нюансами. Вот на MAC уровне есть простарнство для фантазии, чем они и пользуются
Стандарт пишут пару сотен разных инжинеров различной кваливикации и потом за это все голосуют. Так что при таком подходе ожидать ясности мысли в документе не приходится.
Теоретически форум должен когда-то написать рекомендации по приминению стандарта, но так как это работа во многом скучная, никто там ей особо не занимаеться.
Все просто делают а потом собираются на plugfest и проверяют как друг с другом работает. Иногда что-то проскакивает в преписках на форуме. Народ задает вопросы а потом кто-то добрый отвечает. Но тако бывает не часто а PHY еще реже.

Основное для разработки PHY (ИМХО) иметь модель и оборудование для тестирования. В частности Agilent делает много для Wimax (ADS2008 и генераторы сигналов). И в их тулзах часто можно почерпнуть нужную информации. Однако полезней стандарта ничего не найти.

Основная идея стандарта заключается в том, что оборудование будет реализовано не на ПЛИС, а на специализированных микросхемах. А на ПЛИС дешево - не реально. Коррелятор там не так много занимает, просто надо знать как его делать За подробностями в личку
Их формировали от балды, главное что в один момент времени - работает один "вид" преамбул... Они нужны чтобы определить сегмент и прочие параметры, чтобы преамбулы от разных баз не путались... Правильнее сделать загрузку эталонных отсчетов для каждого из видов преамбул, а коррелятор он все тот же...
Меня никогда не покидала мысль о том, что в случае wimax это... ТАК, Привет, единомышленник
То же самое могу сказать и про 802.11b... Это чистое надругательство над мозгом. Типа, Intel и прочие богатенькие между собой договорятся и реализуют по быстрому совместимое оборудование, а другим и не положено знать =(
Преамбула это еще цветочки, вот с мобильным ваймаксом его физическим уровнем запросто можно до суицида с массовыми жертвами дойти... Нет нигде справедливости! =(

Написал тебе в личку


Ммм... а как handover тогда делатся? Как определить какие базовые станции в округе? По очереди проверить все преамбулы, перезагружая коррелятор?


Привет


Ммм... странно с 802.11b у меня никакого геморра не было. А в чем у тебя проблема?


Да уж, постарались они там. Извращенцы

Всем привет!
Решил потягаться с TPC стандарта IEEE 802.16.
Практически сразу уперся рогом в стену непонимания..
В спутниковых модемах TPC по этому стандарту имеет кодовые скорости: 5/16, 21/44, 0.495, 3/4, 0.793, 7/8 и 0.95.
Нашел в сети документ на ядро декодера TPC этого же стандарта.. там кодовые скорости какие угодно, но только не эти... единственное совпадение по 0.793.
Каким образом они умудрились получить 21/44 или 0.495? Перебрал все возможные пары.. рядом есть.. но чтобы так точно ни в одно значение не попал...

TPC очень гибкие коды, если говорить о скорости кодирования. Кроме классических 2D конструкций могут применяться трехмерные, расширенные и перфорированные, сами композитные коды Хемминга можно сделать укороченными, удалять строки и отдельные биты, плюс имеются еще коды с проверкой на четность. Все эти степени свободы и позволяют получить практически любую скорость кодирования. Поищите документацию на AHA4540, там хорошо об этом расписано.

Определились с алгоритмом декодирования?

У меня есть документация на aha4501. Там действительно есть формула кодовой скорости с учетом различных вариантов кодов Хеминга и различными манипуляциями с ними. Хочется верить, что 7/8 они получили стандартными скоростями. Как я заметил там 2 этапа кодирования и 2 коэффициента. С ними вчера покрутился.. получил коэффициенты 0.495 и 5/16. Есть мысль, что добавление синхрометки также вносит вклад в итоговый коэффициент кодирования. Но нужно знать длину блока и длину синхрометки.
Что касается алгоритма декодирования, то не буду далеко ходить и сделаю аналогично стандарту DVB-S2 с помощью Max-log-MAP.

тоже так думал

Может Min-Sum?

Вы меня совсем запутали) Ранее делал TPC по стандарту DVB-RCS (не S2 - я ошибся). TPC делал на основе max-log-MAP. Потом делал LDPC по стандарту DVB-S2, вот там был алгоритм min-sum. Сейчас взялся за стандарт IEEE 802.16. Видел описание аналогичное DVB-RCS, потому и решил не заморачиваться и сделать на его базе, если его можно на min-sum как то сделать, то рассмотрю этот вариант.
Сейчас больше беспокоят исходные данные с коэффициентами кодирования.
Удалось выцарапать из вражеского модема информацию о том, что кадр BPSK, 5/16 имеет преамбулу в 32 бита и длину блока в 3840 бит. Поковырялся с коэффициентами и вроде как 5/16 можно попробовать сделать на 2-х размерном коде (16,11) на (16,11) и коэффициентом 2/3.. набрасывая еще метку получаем 5/16. А вот c 21/44 такой номер не прошел... почему то не удается засинхронизироваться по метке... она вроде такая же, но больше первого случая. Сейчас прервусь на отпуск в 9 дней и снова в бой)

максимальный код для TPC какой?
32х26 или 64x57 или 128x120

Как легко Вас запутать. DVB-RCS - это двубинарный рекурсивный систематический сверточный турбокод, TPC - блоковый турбокод, оба могут быть декодированы с помощью MAP или его аппроксимаций. DVB-S2 - это LDPC код и декодируется, как правило, с помощью Min-Sum.

Вы не подскажите, что обозначают в TPC коды (128,127)x(128,126) или (64,63)x(64,62). Как с ними работать? Для чего нужны?
PS Таблицы взяты из описания ИМС aha4540

Спасибо...

Это двумерные коды с проверкой на четность, усиленные по Y оси еще одной дополнительной проверкой (hyper axis), как формируется уже не припомню, давненько было

Это я уже понял, но все так поверхностно написано, хотелось бы каких то подробностей - по декодированию и кодированию таких кодов
Может материалы остались или ссылки?
можно в личку...

Пока особо не вникал в кодирование. Хочу разобраться в исходных параметрах для начала. Действительно в DVB-S2 описан сверточный турбо-код (ТСС), а в стандарте WiMax и сверточный (TCC) и блочный (TPC). В одной из статей написано, что для TCC нужна лицензия France Telecom и приведена пара недостатков по сравнению с TPC. Для TPC как я понимаю, лицензия не требуется.
Так вот во многих модемах для формирования TPC-кода используется микросхема AHA4501. У нее есть ограниченный набор кодов Хемминга с параметрами (4,3), (8,7), (16,15), (8,4), (16,11), (32,26) и (64,57). Вроде как есть незначительное отличие от WiMax в наборе.
Чтобы получить кодовую скорость для BPSK в 5/16 не хватает предоставленных вариантов. А формирования укороченных кодов микросхемой я не увидел. Кроме того, добавляется синхрометка, которая корректирует кодовую скорость.
В данном случае кодовый блок имеет размер 3872 бита, из которых 32 бита синхрометка. Как они умудрились тогда получить 5/16? Сама синхрометка вставляется в кодовое слово, затирая данные или все же идет дополнительное сжатие данных?
Т.е.:
5/16=(Kx2/Kx1)*(Ky2/Ky1)*(Kz2/Kz1)*(3840/3872) - с учетом коррекции кодовой скорости синхрометкой
5/16=(Kx2/Kx1)*(Ky2/Ky1)*(Kz2/Kz1) - без учета.

Пробовал посчитать коэффициенты и для 2D-кода, и для 3D-кода, и с учетом синхрометки и без учета - не получается ни в каких случаях.
Может они после микросхемы как то укорачивают код? В блок-схеме одного из модемов стоит отдельно AHA4501 и за ней блок вставки синхрометки. Упоминания про укороченный код нету(
Вот такая печалька...

Наоборот, DVB - открытый стандарт, для TPC требуется лицензия

Никому верить нельзя.. не смог, к сожалению, снова найти источник..
Сегодня случайно увидел, что в кадре с преамбулой на BPSK, 21/44 присутствуют нулевые вставки. На блок с одной синхрометкой размером в 25168 бит приходится 80 бит преамбулы и 28 вставок по 28 нулевых бит. Попробовал их учесть, но снова мимо, 21/44 никак не получается(

Удалось похоже разобраться с кодовой скоростью 5/16.
Ее можно получить с помощью укороченного 3D-кода с коэффициентами (15,10), (16,11), (16,11).
Учитывая длину блока в 3840 бит и длину преамбулы в 32 бита имеем:
(10/15)*(11/16)*(11/16)*(3840/3872)=0.3125=5/16
Ура! Ура! Ура!))
Теперь повозимся с кодовой скоростью 21/44...
Повозился..
Учитывая длину блока в 25088 бит и длину преамбулы в 80 бит имеем:
(11/16)*(26/32)*(42/49)*(25088/25168)=21/44

подскажите а где 21/44 с такими параметрами используется?

когда я занимался турбиками, по-моему параметры у 21/44 были немного другие = (28,22)*(32,26)*(4,3)*7

вопрос как Вы использовали (4,3) при декодировании?
+
вопрос

до нужного BER "вытягивали" коды по осям X и Y. по оси Z четность использовал как вспомогательный код, который "помогал" иксу и игреку. четность не сошлась - все метрики минус "один", сошлась - наоборот.

а Вы как?


на домашнем компьютере документы по этим кодам ((128,127)x(128,126) или (64,63)x(64,62)) - утеряны. если найду - то в дам знать

спасибо
Разбираюсь пока нет понимания...

21/44 - это кодовая скорость спутникового модема при модуляции BPSK или QPSK. Модемы как импортные, например CDM-600L, так и отечественные, например ЭТРА-МД4L. В обоих модемах используется микросхема AHA4501. Чуть выше я предложил свой вариант получения этой скорости, основываясь на параметрах этой микросхемы и зная длину кодового слова и длину преамбулы. Очень возможно, что на самом деле использованы немного другие параметры кода, но у меня получилось с теми, что я привел.

А как в-принципе формируется 3D-кодовое слово? Данные в куб записываются в какой очередности? Они как то по очереди пишутся в лицевую грань слева направо, а потом в следующий слой по оси Z? Чтобы получить кодовое слово нужно 3 кодера, работающих параллельно и формирующие одновременно грани по осям X,Y,Z или как? Или может нужна какая то опорная частота, превышающая скорость данных в разы и с помощью одного кодера происходит заполнение куба? Я уже голову сломал, в ИНЕТе очень скудно информации...
Самый полезный документ для меня пока вот этот:
http://www.ieee802.org/16/tg1/phy/contrib/802161pc-00_35.pdf

Для 2D данные записываются по строчно (как я понял).
Например для (64,57)x(46,39) записываются строками по 64 элемента. Всего строк будет 46.
Третье измерение например (4,3) или (64,63) как я понял из интернета/форума - это проверка на четность, но как ее делать/использовать мне не понятно.
Просьба если разбиретесь с третьим измерением или с ”enhanced” Turbo Product Codes (eTPCs)" прошу поделиться информацией.

могу выслать программу для формирования кодов tpc. для пробного декодирования. есть поддержка 2д и 3д. еслу нужно - дайте знать

если не сложно, можно и мне на diod2003 собака list.ru

нужно, если можно на scair собака ukr.net

Спасибо.

И мне) И мне)) На andrusha_grig-v@mail.ru) Спасибо)
По поводу реализации кодера... В Инете есть описание ядра кодера фирмы Xilinx:
http://www.xilinx.com/support/documentatio...coder_ds211.pdf
Так вот... там прописано, что для кода (8,4)*(8,4) задержка составляет 13 тактов. Вообще TPC-кодер для этого стандарта не имеет задержки. Походу эти 13 тактов тратятся на сохранение данных в ячейках памяти, таким образом, чтобы при формировании проверочной информации не использовались одновременно ячейки в которые нужно записывать и считывать. Формирование проверочной информации на мой взгляд должно происходить параллельно двумя кодерами после 13 такта, тогда мы уложимся в нужное число тактов кодового слова. Задержка 13 тактов также позволит уже иметь входные данные для 2-го кодера, работающего по оси Y.
Что касается 3D-кодов, то там видимо нужно заполнить минимальное количество куба данных, чтобы возможна была работа одновременно 3 кодеров.
Пока не ясна проблема организации памяти, будем еще подуматЪ)

нашел это, в конце есть исходник на С

Дошел до грани реализации кодера... Но уперся в один момент. Например, если у нас 2-D код с параметрами (n,k)*(n*k), то с помощью одновременной работы 2-х кодеров мы можем получить k-строк и k-колонок проверочных бит. А оставшиеся ячейки проверочных бит мы заполняем битами полученными от строчного Х-кодера или Y-кодера работающего с колонками?
Без интерливинга, мы должны считывать данные слева на право каждой строки по очереди. Если мы проверочные данные строки k+ будем получать Y-кодером, то мы не сможем же выдавать данные TPC-кодером непрерывно и нужно будет вводить дополнительную задержку, нежели если бы мы формировали эти проверочные биты X-кодером.
Из статей мне почему то представляется, что проверочные биты проверочных бит формируются именно Y-кодером.
Кто-нибудь из Гуру может прояснить ситуацию?

Именно так

Тогда совсем не понятно как Xilinx умудрился получить задержку выходного сигнала кодера (8,4)*(8,4) в 13 тактов. Мне казалось, что они как раз идут на задержку входных данных до того момента, пока не сможет по колонке работать Y-кодер. Или там проверочные биты проверочных бит в выходном сигнале считываются по колонке, а не по строкам?

Насчет Ксайлинкса не скажу, но в канал биты "уходят", как правило, построчно

Всем привет! Вот и пришло время связать меня крепкими узами любви с BTC-декодером стандарта WiMAX. Покопался в ИНЕТе, информации очень мало и она скудна. Лишь только в одной статье наших китайских друзей удалось найти более-менее разжеванную версию декодера. Но и в ней не очень много ясности. Исходя из просмотренной литературы многие склоняются к использованию алгоритма Чейза в этом типе декодера.
Как я понимаю на данный момент, процесс декодирования заключается в поиске среди мягких решений полученного кадра 2 или 3 значений с минимальными вероятностями. Какое количество брать и в связи с чем не очень понятно. Видел пример с 3. Это нам дает возможность сформировать 2^3=8 тестовых последовательностей. Далее проводим декодирование жестких решений 8 тестовых последовательностей, где на позициях с малой вероятностью располагаются все возможные биты, какие там могут быть, т.е. с целью перебора всех возможных вариантов. После декодирования БЧХ-декодером, получаем 8 возможных исправленных вариантов. Далее сравниваем их с кадром из мягких решений, смотрим какое максимально приближено, то и выбираем. Как получить далее новые мягкие решения мне пока не понятно, но пока еще рано.
В чем собственно вопрос?) В статье нашего китайского друга приведены несколько другие этапы декодирования. И в начале они делают жесткие решения, по ним проводят БЧХ-декодирование и получают синдром. Далее ищут позиции с самыми низкими вероятностями и выполняют какие то магические манипуляции с полученными данными.
Вообще полученный синдром нам уже дает позицию с ошибкой (декодер Хемминга как я понимаю способен исправить только 1 ошибку), в том случае, если она одна.. если больше, то позиции 2-х и более ошибок не определить.
Статью и блок-схему прикрепил к сообщению. Кто-нибудь из гуру блочных турбокодов может прокомментировать сложившуюся ситуацию?

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