[gegel 0]

Хотелось услышать мнение о возможности проброса модемного соединения >=1200bps через сжатый речевой канал: GSM/UMTS (GSM-FR, -EFR, -HR, AMR), Skype (Silk), SIP (G723, G729 etc.). Какие алгоритмы модема целесообразно пробовать?

[thermit 1]

гы. ну вот, например

[microstrip_shf 0]

Мы пробовали пропускать через ЖСМ 4-6 несущих с 2PSK , очень неплохо выходило и удавалось до 2 килобит пробрасывать, но ввиду того что канал не стабилен и база кодеки может сама перестраивать скорость иногда просаживается. Проверяли между операторами и на международных каналах, там все было похуже.

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

[gegel 0]

гы. ну вот, например

Спасибо, буду пробовать как вариант. Искал в исследовательских работах, а, оказывается, все есть в ETSI. Стандартам больше доверяю, тем более eCall.

 

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

Пробовал рекомендованый шведом вариант для GSM-FR (используя каждый третий сэмпл) - хорошо, но только для FR.

 

Мы пробовали пропускать через ЖСМ 4-6 несущих с 2PSK

Аналогично экспериментировал с FDMDV

(14-16 модемов по 50 bps каждый), с переменным результатом. На каких частотах и с каким битрейтом вы использовали 2PSK?

 

Есть еще статья с результатами по 4QAM, там четко показан оптимум для частоты и фильтра.

 

чтобы его ЖСМ кодек не резал через некоторое время.

Проблема VAD обсуждалась по последней и предпоследней ссылке. В частности, в Сурерйском проекте каждый 100 мсек на 20 мсек применяли постфильтр. Все VAD, судя по описаниям ETSI, считают фреймы незвуковыми в случае монотонности спектра.

 

Интересно, что можно предположить в китайском проекте, судя по ролику на youtube? Они утверждают, что проходят и GSM-HR, и AMR-4.75, причем не ниже чем на 1200 bps. Судя по специфическим звукам, без CELP там не обошлось, но все же я не музыкант.

[gegel 0]

Решил опубликовать небольшой отчет о моих экспериметах по теме, может, кому-то будет интересно. Это мой дебют в DSP, поэтому, хотя прочтение Скляра и творит чудеса, надеюсь на помощь зала.

 

Небольшой обзор:

 

Теоретическая оценка емкости сжатого GSM канала, рекомендации по субоптимальному декодированию:

http://www.nativitysoftwares.com/downloads...M%20Network.pdf

 

Метод кодирования позицией импульсов:

http://signal.ee.bilkent.edu.tr/defevent/papers/cr1512.pdf Классика от Кондоза (Суррейский университет)

http://www.diva-portal.org/smash/get/diva2.../FULLTEXT01.pdf Швеция, адаптации метода Кондоза для различных кодеков

www.3gpp.org/DynaReport/26268.htm Практическая реализация eCall-модема (Qualcomm)

 

Адаптация классических модуляций:

www.news.cs.nyu.edu/~jinyang/pub/hermes.pdf DFSK

http://www.esiee.fr/~chmaysst/RadioElektro..._finalpaper.pdf Франция, 4QAM и 4FSK

http://publications.lib.chalmers.se/record...ltext/72428.pdf Шведская дипломная: DPSK vs Syntetic

http://www.mii.lt/informatica/pdf/INFO745.pdf Чехия, PCCD-OFDM-ASK

 

Использование тональных псевдоречевых символов (Syntetic):

Работы Сапожникова (Автралия) по выбору алфавита методами стохастической оптимизации

http://v3solar.com/wp-content/uploads/2014...ueIEEEpaper.pdf

http://lib.gen.in/next/MTAuMTAwNy9zMTEyNjU...zhnykov2012.pdf

 

http://www.wseas.us/e-library/conferences/...st/33-CISST.pdf Иран, использование 3-х частотных символов

http://www.eurasip.org/Proceedings/Eusipco.../1569925355.pdf Иран, идея с расширением спектра

 

Кодирование данных в описателях голосовых кодеков:

http://www.emo.org.tr/ekler/acb89c94a3adb43_ek.pdf Турция, использование параметров GSM FR кодека

 

Основная цель - реализация криптофона. Получилось зафиксировать кодеки (GSM FR, EFR) с помощью АТ-команд GSM модулей Quectel. Поэтому, в отличие от универсальной приставки JackPair (ныне почившей?), кажется более практичным использовать свое железо и в части GSM. Модули позволяют встраивать пользовательский код в ARM чипсета в виде отдельной задачи. Планирую реализовать внутри модем, и подключасться к нему через блютуз модуля. Второе преимущество - исключение асинхронного аналгового аудио интерфейса между GSM и декодером.

 

После шатаний решил отказаться от Syntetic-методов (хотя они наиболее перспективны для низкобитрейтных кодеков типа AMR475) и попытался скрестить метод Кондоза с классической модуляцией. Результаты очень даже неплохие (лучше предлагаемых классических схем, в т.ч. и Hermes) - BER=10^-5 для GSM_FR/EFR при 1200bps. Другие кодеки: SILK 0.5*10^-2, G729 10^-2, ILBC 2*10^-2

 

Т.к. планировалось использовать MELPE1200, определил его битрейт как минимально необходимый, и структуру модема подганял под его блоки. Перепробовал множество варинатов модуляций, и убедился, что свойства канала концептульно отличаются от AWGN c вытекающими последствиями: снижение битрейта оптимальнее любых схем кодирования при любом оверхеде. Основным источником ошибок был джиттер фазы за счет аснихронной работы тандема кодеков канала и PCM сигнала, причем при небольших разностях сэмплрейтов (доли герца) иногда складывались очень неблагоприятные соотношения сдвигов, и шли пакеты ошибок длительностью в секунды. Никакой FEC не поможет, учитывая реалтайм-требования к голосовой связи.

 

Логичным был выбор BPSK сигнала 1333Hz (ровно 3+3 сэмплов на период c максимумами во 2-м и 5-м пульсах, прекрасно для RPE механизма GSM-FR). Другие (4- и 8-арные решетчатые) схемы с витерби и БЧХ давали худшие результаты. Эта схема давала хорошую возможность для фазовой синхронизации, поэтому применил когерентное декодировоание. Почитал Скляра, и навесил адаптивный еквалайзер.

 

Опционно добавил два варианта блокировки срабатывания VAD: шейпер (по Кондоз) и снижением амлитуды (идея от авторов hermes), оба работают и не добавляют BER/потерю синхро, важно выбрать интервал применения - от 67.5 до 270 mS нормального и измененного сигнала).

 

Т.о. получилось передать 90 бит в 540 сэмлах. Полезные 81 бит (MELPE1200 фрейм) разбил на 9 символов по 9 бит + бит четности. Интерливил данные: передаю сначала биты 0 всех 9-ти символов, потом биты 1,... в конце биты четности. Используя мягкое декодирование, в каждом символе могу корректировать бит с минимальной метрикой при ошибке четности. Такой простейший FEC позволяет вероятно исправить вспышки ошибок до 9 бит подряд (54 сэмла) в блоке 90 бит, что больше субфрейма кодеков (5 mS, 40 сэмлов) и не кратно ему.

 

Биты четности также используются для синхронизации "на лету" на границу блока: адаптивный механизм позволяет "ловить" синхронизацию уже на 3-м блоке (200 mS с любого места потока), и удерживать вплоть до 2% разницы между сэмплрейтами модулятора и демодулятора. Никаких стартовых синхро, трейнинг и т.п., особое внимание уделено жесткой синхронизации счетчиков блоков, т.к. они будут использоваться в крипто (CTR режим шифрования).

 

Тестовая реализация модема выполнена на С и использует аналоговый аудио интерфейс PC. Для обеспечения лучшей синхронизации используется сэмплрейт 48000Hz, и код модема заточен под него. Вариант с 8000Hz дает тот же BER при рассоглавании сємплретов менее 0.5% (что не всегда достижимо на реальных PC, см. блоги по FreeDV http://freedv.org/tiki-index.php

и SmarthMic http://www.rowetel.com/blog/?p=3125

), еще менее ресурсоемок и будет встроен в GSM-модем Quetel M66 с использованием цифрового аудио, уже синхронного с сэмплированием.

 

Код собирается gcc на Linux, mingw на Windows (пока не готов вариант с NDK для Android) и использует alsa/wave аудио. Исходники и готовые статически линкованные бинарники (работают практически на любой 32/64 версии ОС) можно посмотреть тут: http://torfone.org/download/gsmmdm2.zip

 

После более тщательного тестирования выложу на github. Хотелось бы услышать замечания и советы.

gsmmdm2.zip

[des00 25]

Решил опубликовать .....

респект и уважуха :)

 

[Милливольт 0]

Решил опубликовать небольшой отчет о моих экспериметах по теме, может, кому-то будет интересно.

 

 

 

 

Спасибо, о некоторых работах и понятия не имел, очень полезно.

Мы занимаемся этой проблемой лет 12 (для транстелефонной ЭКГ), и выяснили печальную зависимость: чем ближе к реальным сетям, чем ближе к реальным телефонам, - тем дело хуже. В итоге ограничились чуть более 250 бит/сек т.к. оверквоттинг в реальных линиях, АЧХ трактов разных мобильников и прочие радости... В общем, при многолетней эксплуатации аппаратуры (около 80тыс. передач в год) кроме как двухчастотный FSK с непрерывной фазой ничего нам не помогло. В популяризаторском варианте описал здесь: http://www.tredex-company.com/ru/kak-rabotaet-telecard

А Вы хотите сделать что-то типа ЗАС для мобильника?

 

[gegel 0]

для транстелефонной ЭКГ

Коллега, а Вы не с UA? :rolleyes:

А Вы хотите сделать что-то типа ЗАС для мобильника?

Да, что-то типа GSMK Cryptofone:

http://www.cryptophone.de/

но вместо CSD, повсеместно блокируемого операторами на общих тарифах, с акустическим модемом.

Я анонсировал проект в прошлом году на русскоязычном криптографическом форуме:

https://www.pgpru.com/forum/prakticheskajab...tnogoskremblera

Но буквально через месяц китайцы презентовали точно то же на кикстартере:

https://www.kickstarter.com/projects/620001...ne-conversation

причем получили бешеную популярность (даже в блоге Шнайера положительно засветились):

https://www.schneier.com/blog/archives/2014...air_encryp.html

но потом пропали, и уже год тянут резину, типа выбирая упаковку для изделия :rolleyes:

Их модем использует конечный алфавит, его можно послушать на youtube:

https://www.youtube.com/watch?v=rh6yF79FkAA

Но мне кажется, что именно тут у них проблема.

Еще обещал с подобным решением помочь David Rowe, автор Codec2:

http://www.rowetel.com/blog/?p=3667

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

 

кроме как двухчастотный FSK с непрерывной фазой ничего нам не помогло

Фактически это hermes-модем (NY университет, см. ссылку выше). Действительно хорошо для неизвестного акустического канала. Я пошел немного другим путем: не универсал под любое железо/кодек, а выбрал конкретный GSM-модуль (Quectel M66), зафиксировал в нем кодек как FR/EFR (любая сеть должна поддерживать FR) и сосредоточился именно на этом кодеке, держа в уме его механизм (RPE) при выборе baseband-сигнала для модема. Еще помогли исследования в шведской дипломной, там есть рекомендации именно для FR. По идее, для FR получилось лучше, чем hermes.

 

чем ближе к реальным сетям, чем ближе к реальным телефонам, - тем дело хуже

Вот с этим я тоже столкнулся, сейчас тестирую на двух GSM-китах, пока с аналоговым аудио. И если на аппаратном фреймворке я легко получал 10^-5 на 1200 bps, то в реале вышел лишь на 0.5*10^-2, кроме того, пришлось увеличить окно для лока фазы в коде по ссылке выше. И еще наблюдаются интересные эффекты: LLR на выходе коррелятора некорректный, да и сам коррелятор с полным периодом BPSK работает хуже, чем только с первым полупериодом (а со вторым - вообще плохо). Наверное, результат LPC long term фильтрации. Есть заметное снижение BER при введении асимметрии в BPSK-сигнал в модуляторе. Также буду пробовать ввести управляемую межсимвольную интерференцию в самом модуляторе и подобрать вейформу, а также пробовать различные фокусы в корреляторе демодулятора в плане оптимизации LLR для мягкого декодирования. В общем, огромное поле для креатива. :rolleyes:

[Милливольт 0]

Коллега, а Вы не с UA? :rolleyes:

Харьков

 

Также буду пробовать ввести управляемую межсимвольную интерференцию в самом модуляторе и подобрать вейформу, а также пробовать различные фокусы в корреляторе демодулятора в плане оптимизации LLR для мягкого декодирования. В общем, огромное поле для креатива. :rolleyes:

 

Поле действительно огромное. У нас при работе с реальными линиями (не компьютерными имитаторами) выяснились такие неприятные вещи: 1. Нельзя ориентироваться на "классику" - практически все помехи - негауссовы. 2. Вся межсимвольная кухня хорошо решается только с окном Фейера (мы его изобрели раньше, чем прочитали). 3. На ошибку менее 1*10-3 можно рассчитывать только в 4 часа утра и только на подобранных предварительно телефонах. Во все остальное время следует рассчитывать -2, а в дневное время где-то 0.5*10-1 4. Когда система входит в оверквоттинг - это беда. Пришлось применять вот такие методы: http://www.tredex-company.com/ru/printsip-...dannykh-dannykh (там есть некоторое сгущение красок с моей стороны - сейчас очевидные идиотизмы в организации связи стали поменьше).

 

[gegel 0]

Вся межсимвольная кухня хорошо решается только с окном Фейера

Я смотрю на BPSK в time domain, возможно, в этом есть свое преимущество (по крайней мере, для FR), а может и нет.

Пришлось применять вот такие методы

К сожалению, шифропоток по определению псевдорандомен, поэтому для криптофона это не годится.

Но для ЭКГ идея интересная, вот только главное не "переборщить", т.к. если имеющиеся паттерны будут сильно "притягивать" к себе сырую кривую, то можно пропустить мелкие детали (например, исказить степень поднятия ST, что приведет к неверной оценке степени ишемии и т.п.).

Более 10 лет назад я делал приставку и диспетчерский модем под стандарт "Волны" на ОУ MCP и MC PIC, но не знал, что это до сих пор актуально: мир сильно изменился, и сейчас я бы использовал другие подходы. Напишите мне на почту (в шапке C-файлов модема по ссылке выше), чтобы не переходить в оффтоп.

[Милливольт 0]

К сожалению, шифропоток по определению псевдорандомен, поэтому для криптофона это не годится.

Не могу согласиться.

Мною приведена иллюстрация для многоканального сигнала, оцифрованного ДИКМ, и самое главное, сжатого компрессором, уже использующим априорные знания характеристик сигнала. Понятно, что при такой оцифровке внутриспектральные связи сигнала разрушены, а восстановление может идти только за счет неполной межканальной ортогональности.

Если же оцифровка обычная, а сигнал речевой, т.е. имеющий значительную марковость, то коррекция искаженных отсчетов резко упрощается http://tredex-company.com/ru/ispolzovanie-...uyuschikh-kodov (извиняюсь за самоцитирование, но место на форуме экономлю). Там есть и примеры восстановления речевых сигналов.

Т.о. от системы кодирования/шифрования/дешифрования/декодирования требуется лишь классическое "перемежение" (для исключения длительного выпадения корректных данных в потоке) и отсутствие "взбивания" при шифровании. Товарищ Вернам вполне в теме.

[gegel 0]

Относительно криптофона позволю себе попытаться отстоять свою точку зрения: криптоданные, подающиеся на модулятор, рандомны и не могут быть сжаты. Более подробно о шифровании: после согласования сеансового ключа и его аутентификации долговременными PGP-ключами участников используется потоковое шифрование (точнее, CTR-режим) с целью минимизации искажения единичного бита на процесс дешифрования пакета. Используются синхронизированные счетчики отправленных и принятых пакетов (фреймов) и качественная псевдорандомная (RO-PRF) хеш-функция Keccak: Sponge абсорбирует сеансовый ключ и номер пакета, затем выжимает гамму, с которой ксорится тело пакета. После ксора с рандомом получаем неотличимые от рандома данные для передачи по каналу связи.

Конечно, сжать данные (речь) можно (и нужно) до шифрования. Но это задача используемого кодека, и изобретать велосипед тут не стоит: сделать лучше, чем MELPE, на коленке вряд ли получится. Кстати, кодек имеет встроенную легкую FEC, и при критических ошибках фреймы восстанавливаются именно на основе статистики предыдущих.

 

Оффтоп:

по поводу сжатия ЭКГ тема очень интересная и сложная, и несравнимо уже, чем сжатие речи, отсюда менее проработанная. Например, сразу бросается в глаза периодичность (по аналогии с pitch). Более того, сжатие сразу нескольких отведений может успешно эксплуатировать связи между ними. На вскидку видится эффективным выделение периода ЭКГ (ЧСС) и использование дифференциального кодирования с компактными описателями изменений (например, экстрасистолы или блокады IIст. с прогрессивным удлинение ST вплоть до выпадения QRS). Я не встречал работ, посвященных этой теме, но думаю, что при правильном подходе можно добиться очень высокой степени сжатия при сохранении достоверности, гораздо больше, чем речи. Основное отличие: при сжатии речи требуется сохранить разборчивость при допустимой потере индивидуальных характеристик, а при сжатии ЭКГ необходимо безусловное сохранение четко определенных особенностей кривой с возможностью частичного игнорирования других незначимых для диагностики.

[Милливольт 0]

Относительно криптофона позволю себе попытаться отстоять свою точку зрения

 

Оффтоп:

по поводу сжатия ЭКГ тема очень интересная .

 

Позвольте начать с оффтопа.

Наши собственные работы в этой теме дали такие результаты сжатия ЭКГ, что их даже неприлично показывать. Метод предельно простой: на базе вычисления корреляций между QRS комплексами формируются классы этих самых QRST. В реальной ЭКГ этих классов мало: на суточной записи типичное число - 20, а больше 50-ти мы вообще никогда не видали.

Дальше все просто: один раз передаются образы, т.е. классы сокращений, а дальше передается RR интервал и номер класса. Восстановленная ЭКГ абсолютно неотличима от исходной при отстутствии помех. В случае помех восстановленная, понятное дело, "чище" исходной. Проблемы были только при АВ блокадах, когда нужно было точно восстановить характер биений P-P относительно R-R.

 

Теперь по поводу криптофона.

А почему нужно поступать только так, как Вы описали? Может быть, сделать проще, типа записать гамму изначально при непосредственном общении двух криптофонов (шифроблокнот).

Или Вы хотите иметь гарантированную стойкость, в том числе и для вновь входящих в сеть абонентов?

Ну, так это гиперзадача. И она, если будет решена, то решите ее не Вы, не Боб и не Алиса. Решит Ева; она с помощью СОРМ, - обнаружив криптопоток, - возьмет за нежные части и Боба, и Алису, сломает пару ребер или применит ТАП-57. И на том игры в розенкрейцеров будут окончены.

Т.е. криптофон без серьезной стеганографии - получается вещь в себе, искусство для искусства?

[andyp 9]

Т.е. криптофон без серьезной стеганографии - получается вещь в себе, искусство для искусства?

 

Схема, описанная GeGel, при правильной реализации защитит от man in the middle атаки, при этом не требуется личная встреча абонентов для обмена ключами. Также, при попадании телефона одного из абонентов в нехорошие руки, чужие ключи не компроментируются (максимум, что найдется, так это единственный private key, привязанный к этому телефону). Еще народ делает дополнительно голосовую аутентификацию, чтобы другая сторона убедилась, что Вы - это Вы. Сессионные ключи и рандомизация также нужны, так как помогают от known plaintext атаки (что вполне можно замутить, зная, что вокодер передает comfort noise в паузах речи). Симка с телефоном после серьезных разговоров выбрасывается, так что не все так просто.

 

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

 

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

[gegel 0]

В реальной ЭКГ этих классов мало: на суточной записи типичное число - 20, а больше 50-ти мы вообще никогда не видали.

Очень интересные исследования, хотя есть одно но: по уму необходимо математически показать вероятность неподдерживаемого класcа, определяющего диагноз. Т.е. фактически это будет вероятность ошибки диагноза. Если достигается, скажем, Р<0.05, то это приемлемо в медицине.

Хотя есть масса участковых врачей, которые знают и используют всего 20 диагнозов и прекрасно работают. Но все же я бы не хотел к такому попасть.

 

Вы хотите иметь гарантированную стойкость

Конечно же, в качестве противника обычно рассматривается АНБ, а не младшая сестра :rolleyes:

возьмет за нежные части и Боба, и Алису

ну, дискуссия между академичиской криптографией и реальностью может быть бесконечной.

Есть такие понятия, как Perfect Forward Secrecy, Plausible Deniability, Forward Deniability.

Согласен, в случае криптофона математическая отрицаемость (например, в плане использования своего PGP-ключа) малополезна, т.к. соединение в принципе неанонимно (по sim-карте). Но PFS обязательна в современной крипто, и без ефемеральных сесионных ключей, выведенных Диффи-Хелманн, это было бы несерьезно. Для защиты от MitM необходима аутентификация:

- биометрическая (голосовая) - ненадежна;

- общим секретом - требует протоколов с нулевым разглашением, ненадежна в плане key impersonation attack;

- публичным долговременным ключом в составе цепочки PKI (например, PGP, подписанным другими).

 

Еще народ делает дополнительно голосовую аутентификацию

сейчас считается ненадежной ввиду широких возможностей голосового анализа/синтеза, тем боле после обработки голоса MELPE1200. Дополнительно - да.

 

Но если код открыт, то как на этом заработать деньги???

Код обязательно должен быть открыт, иначе это несерьезно. Есть идея четко разделить код на доверяемый и недоверяемый, разместить в разных HW. Доверяемый код осуществляет крипто

и полный контроль интерфейсов между HW. В таком случае недоверямый HW/FW можно рассматривать как часть линии связи, закрыть его код и использовать как коммерческую составляющую проекта, неразрывно связанную с открытой частью.

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

 

Все это тоже не добавляет оптимизма.

Сейчас тестирую на реальных сетях, так и есть. Но пока оптимистично, т.е. useability пока видится на приемлемом пользовательском уровне.