eCall в качестве альтернативы для p2p передачи даных Опции

[GeGeL]

Обсуждение 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?

[CADiLO]

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

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

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

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

[GeGeL]

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

Я тоже об этом думал. В реализации 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.

[makran]

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

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