Обсуждение CSD в соседней теме наталкивает на мысль об актуальности p2p передачи данных на фоне непонятного игнорирования CSD как производителями, так и сисопами. На сколько я понимаю, CSD получаем при использовании фактически голосового фрейма, подаваемого не на кодек, а на FEC, т.о. имеем 9600 bps при одинаковой с голосом нагрузке для оператора (или даже меньше, т.к. не надо транскодировать). Так что ограничения тут не технического плана, а скорее коммерческого ИМХО. После разговора с CADiLO проверил: в Украине только Life поддерживает CSD на общих тарифных планах, но, как сообщили в поддержке - неофициально и без никакой гарантии, кроме того, могут и блокировать карту за нецелевое использование (?!).

В итоге имеем 4 классических способа передачи данных (например, опрос датчиков телеметрии) в GSM:
- GPRS: не совсем p2p (требуется IP сервер), абонент должен постоянно поддерживать связь и слать KeepAlive (иметь ненулевой баланс с постоянным расходом средств);
- CSD: в большинстве требует M2M тарифа;
- SMS: доставка не гарантирована как по времени, так и по факту;
- DTMF: в лучшем случае 50 бод.

Но есть интересная альтернатива, о которой ранее на форуме не упоминалось: eCall. Система использует специальный псевдоречевой модем, проходящий через голосовой канал GSM с перезапросами, и позволяет гарантированно передавать блоки данных в 140 байт за время до 10 сек (реально требуется меньше секунды) через обычный головой звонок. Номер не обязательно 112 (можно указать любой).
Исходный код доступен, поэтому для поднятия своего PSAP-сервера достаточно прикрутить аудио (лучше к digital audio bus) и скомпилировать, это на час работы.
И самое интересное: документ GSM_eCall_Application_Notes_V1.2 от Quectel. В модуле реализована поддержка как клиента, так и севрера (для тестирования), т.е. в режиме сервера получаемые данные отображаются через URC. Т.о. с помощью OCPU можно очень просто организовать p2p канал данных по голосовому звонку.

Вопрос к CADiLO: а как обстоят дела с SIMCOM?
И вопрос к Quectel: планируется ли поддержка eCall в M66?

Ну как решение "для поизвращаться" - теоретически реально.
Спецпрошивки eCall для SIMCOM тоже имеются, только тогда теряете много вкусностей из ENHANCED.
Но при цене инета 1 гривна в сутки (МТС) смешно придумывать подобное - UDP будет проще PSAP, а уж быстрее так точно.
А если совсем нужна гарантированая доставка то нормальный клиент просто возьмет M2M пакет.

Хм, сравнивать серверную реализацию и p2p не совсем корректно, они, по сути, для разных задач предназначены. CSD ведь не просто так интересуются: часто выгоднее собирать информацию с точек по инициативе центра. Причем точки принимают только входящие, и даже не требуют положительного баланса.
Кроме того, при наличия режима PSAP в самом модуле это уже чистый m2m, как и csd, без никакой вспомогательной инфраструктуры.

Пользуйте тогда охранный протокол ContactID.
Модули прекрасно генерят и распознают его частоты - 1400 и 2300 Hz.
Во первых - стандартно, во вторых все в аудиоканале - именно как вы и хотите, в третьих без извращений с серверами.

http://www.technoimport.com.co/Producto/pd..._Contact_ID.pdf
http://www.ritm.ru/documentation/manuals/5rt1_chapter_6.pdf

Спасибо за спецификацию в коллекцию. Только 1400 и 2300 там - это handshake, данные там передаются с помощью DTMF (см. п .4.1.2.3 по первой ссылке - 10 бод без коррекции ошибок), т.е. это в точности соответствует п.4 в моем перечне способов p2p.
Конечно, на фоне протокола eCall http://www.etsi.org/deliver/etsi_ts/126200...267v110000p.pdf с FEC на турбокоде и HARQ это выглядит совсем по детски и сердито.
Или на фоне современных исследований по теме, на которые я ссылался в другом разделе форума:
http://electronix.ru/forum/index.php?showtopic=124391
И в каждой из этих работ в аннотации обуславливается актуальность предлагаемого модема в плане или замены дорогих СМС, или создания m2m шифропотока данных поверх GSM голосового звонка со скоростью, достаточной для банковских опеаций, передачи сжатой речи и т.п. Конечно, потоковый модем - это "нишевая" разработка, но eCall как отдельная новая технология передачи пакетов данных может заинтересовать потребителя. Тем более, если будет реализована "из коробки" в прошивке модуля и доступна пользователю с помощью простых АТ-команд, как в Quectel.

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

И повторюсь в вопросом к представителям Quectel: планируется ли поддержка eCall в M66?

>>но eCall как отдельная новая технология передачи пакетов данных может заинтересовать потребителя.

А в Украине кто из операторов поддерживает eCall?

Есть ненулевая вероятность, что МЧС голову оторвет сделает атата за нецелевое использование канала.

Немного не верное понимание сути технологии. eCall - техника гарантийной передачи данных во время аудиозвонка, наподобие DTMF. Основывается на использовании акустического модема, спроектированного для работы через сжатый аудиоканал. Включает мощную коррекцию ошибок, перезапросы, проверку контрольной суммы. Передает пакет 140 произвольных байт (формат пакета не регламентируется).
И технологии этой без разницы, во время какого звонка будет передан модемный сигнал - на номер 112 или же на любой другой номер. Также без разницы отношение к ней оператора: модем спроектирован так, что проходит через любые кодеки: EFR, FR, HR, все AMR от 4.75 до 12.2, и даже TETRA. Поэтому волей-неволей поддерживают eCall все операторы.

Что касается второго вопроса, то МЧС тут вобще не при чем: передача данных с использованием этой технологии между двумя обычными абонентами не имеет отношения к МЧС и номеру 112: это обычный голосовой звонок между обычными абонентами, не более того. А то, что передаваемые звуки не похожи на русскую речь, трудно назвать нецелевым использованием, равно как и пение птиц или мяуканье кошки.

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

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

Поэтому есть два варианта:

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

2. Не заниматься околотехнической фантастикой стараясь прилепить устройство к "жабе" давящей пользователя, а использовать так как и положенно - M2M пакет и оплата за пользование.
Операторы они ведь тоже народ ушлый - прикрыли CSD, прикроют и эту лавочку. А оставшиеся в стороне юзеры пойдут бить лицо производителю железок.

Я тоже об этом думал. В реализации eCall от Quectel, судя по документу, используются команды:
AT+QECCFG=1,”DM”,1 // Turn on IVS mode, DSP starts monitoring eCall related signal
AT+QECCFG=1,”DM”,2 // Turn on PSAP simulation mode
По идее, они активируют задачу модема в режиме клиента или сервера. Мне кажется, работа самого модема не должна быть связана с инициатором и типом звонка, т.е. будет работать и после ATD. Возьму подходящие модули, попробую в ближайшие время на китах. Если кто-то попробует раньше, просьба отписать.
Единственно, что может быть желательно, так это установка кодека и отключение звуковой петли, аналогично как для DTMF:
AT+QAUDCH=0;
AT+QSIDET=0;
AT+QSFR=7;
AT+QMIC=0,0;
AT+CAGC=0,0;



Да ну?

// Set the MSD, hex bytes. This data is just an example. Max data length is 140 bytes, input as 280
characters in hex string format.
AT+QECMSD=c5e165df6a789b4aaaa46ee4a651820daaf625803735d9dfd5c7067927d821a43d4b64
b
74cd2116dc582aabc6f4e45cdf9cbe2f74eb1aaf69cb4ef86cde48f86e02147d6c49ea22587144bb
fdaa8
ef92c04afeb0c4e93ba93453561e65acd5065bbe12abde11819d86434039cf4e619124d5f308240a
b0ea
11635aef2edfc8bc39e77768d784b67f6f7cb603

По поводу остального: просто у нас с Вами совершенно разные цели - отловить клиента на N-тысяч устройств (лучше по распилу бюджета) и академические разработки. Китайцы подстраиваются по реалии бизнеса по русски, но и про перспективу иногда помнят, иначе не было бы никаких новых функций вообще.
И это не хотелки, а, скорее, стандарт, обязательный для европейского рынка, просто используемый не по назначению. По поводу "околотехнических фантазий" вообще повеселило. Самое высокотехничное решение - это, конечно же, решение диллера в сделке на N-тысяч устройств, да.
Прикрыть сисопу eCall технологию ну никак не удастся, см. матчасть. Это то же, что прикрыть DTMF.

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

Честно, интерес к поддержке eCall в M66 (а я уверен, что она будет, во всяком случае, для европейских версий) у меня другой: имея исходный код eCall и компилятор, получаем патерн, ищем его в бинаре прошивки, дизассемблим, находит точки связи с kernel, и лепим вместо eCall свой потоковый модем, пригодный для передачи шифрованного с помощью модерн криптографии голоса, сжатого 1200 bps кодеком. Это "нишевой" продукт.

Но если будет интерес к использованию eCall в качестве альтернативы CSD, DTMF или SMS, без проблем по ходу набросаю исходники PSAP локального сервера, пригодного для сбора информации с модулей в телеметрии, работающего с модулями Quectel или по PCM аудио, или через DAB.

>>>Прикрыть сисопу eCall технологию ну никак не удастся, см. матчасть. Это то же, что прикрыть DTMF.

Гы - проходили. В бытность у нас пчелайна отдельной конторой они чудно зарубили 941 и 1633 герца мотивируя это борьбой с сотовыми мостами.
Разбирательство длилось пару месяцев и все это время DTMF не работал.
А уж отключение Лайфом карточек по одному только подозрению в нецелевом использовании, так это отдельная песня.
Оператор отрубает, а потом доказать что ты не козел уже стоит денег и нервов.

>>>Самое высотехничное решение - это, конечно же, решение диллера в сделке на N-тысяч устройств....

Это не решение диллера, это реальность тех производителей кто работает в правовом поле.
Попробуйте любому производителю охранок или телеметрии - не самодеятельному, а серьезному - подать свою идею.
Первый же вопрос будет - покажите официальные документы регламентирующие такую работу, сертификаты и прочее.
Ах нету, но перспективно? Досвидос - прийдете когда будет пакет документов.
Особенно если устройства потом сертифицировать и прочее. Вот отсюда и делайте выводы....
Не сомневаюсь что с точки зрения самообразования и десятка-другого устройств "на коленке" идея неплохая.
Но вот для промышленного применения закладываться на всякие "может быть" и "перспективное нецелевое использование" - дороже выйдет.

Мне думается, что идея хорошая. Только работать всё это будет до тех пор, пока количество пользователей технологии не превысит некоего критического уровня. После чего ОпСоС найдёт и методы, и средства, и безупречное юридическое обоснование отключить эту самую возможность, если её использование будет невыгодно операторам. А оно ведь будет - если я за две-три секунды могу передать телеметрию в один конец, то ни инициатор связи, ни абонент на другом конце совсем не тратят денег! Будут у ОпСоСов висеть тысячи (если не миллионы - в телеметрии-то!) карт, которыми активно пользуются, но с которых ни копейки не приходит... Не нужно забывать про народное "на каждую хитрую гайку найдётся свой болт с резьбой". Если это Ваша "гайка" - решайте за себя сами, если же это сотни/тысячи клиентов - можно попасть...

Сообщение отредактировал Slonofil - Apr 15 2015, 09:51

Блокировать прохождение eCall/Эра-Глонасс??? А вышеупомянутый атата от МЧС как?
Конечно, можно предположить, что на обычные звонки (кроме 112) будут установлены фильтры в транскодеры, но Вы сами то в это верите?
ПС: могу предположить, что в описанном выше случае блокировали технику AT+VTS (что тривиально), но не AT+QWDTMF. По лайфу: CSD элементарно обнаруживается системой, и может быть элементарно блокировано. Но сканировать ВСЕ голосовые звонки на предмет eCall и блокировать те, которые на самом деле не eCall - задача совсем другого уровня сложности и по стоимости несоизмеримо выше любых убытков от телеметрии.
Опсос - не бог и не волшебник, его возможности вполне конкретны и предполагают четко определенные затраты на глобальные решения, не стоит его ни недооценивать, ни переоценивать.

сомневаюсь.
в детали не могу углубиться, но насколько помню, у оператора звонки по ecall чётко отслеживаются и отличаются от обычных голосовых вызовов.
когда происходит e-call звонок, ему присваеватся специальный флаг и максимальное значение QoS и это даёт ему приоритет над любыми другими соединениями, таким образом ecall почти всегда дозванивается. например если все таймслоты на соте заняты - сота сбросит чужой звонок и даст Вашему устройству провести ecall.
Соответсвенно оператор именно по этой причине и закроет Вам эту функцию. Потому что приоритет должен быть только у экстренных вызовах при дтп, а не для стандартных данных в м2м.

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

Это как вариант, причем работающий.