GPRS для чайников Опции

[ISG2015]

Необходимо разработать систему с передачей данных c использованием технологии GPRS.
Выбор пал на модемы SimCom

Готовых решений не встречал (готов за разумные деньги приобрести) и поэтому вынужден заняться изобретением велика
Несколько вводных вопросов относительно темы:

1. Можно ли организовать GPRS канал связи используя только АТ команды, не пользуясь Embedded AT?
2. После прочтения мануалов и даташитов на тот же Sim900 реализуемо своими силами?
3. Как учесть все особенности и нюансы каждого GSM оператора используя только одни АТ команды?

Буду оч. признателен за любые советы и помощь.

[id_Alx]

Необходимо разработать систему с передачей данных c использованием технологии GPRS.
Выбор пал на модемы SimCom

Готовых решений не встречал (готов за разумные деньги приобрести) и поэтому вынужден заняться изобретением велика
Несколько вводных вопросов относительно темы:

1. Можно ли организовать GPRS канал связи используя только АТ команды, не пользуясь Embedded AT?
2. После прочтения мануалов и даташитов на тот же Sim900 реализуемо своими силами?
3. Как учесть все особенности и нюансы каждого GSM оператора используя только одни АТ команды?

Буду оч. признателен за любые советы и помощь.

1 - можно.
2 - реализуемо.
3 - AT командами можно определить оператора. Особенности работы с конкретным оператором выясняются опытным путем.

[p_kav]

А какой конкретно GPRS? TCP, UDP, почта, WEB? Только отправка данных, или двухсторонний обмен? Есть ли потребность в минимизации трафика?

Сообщение отредактировал p_kav - May 6 2015, 17:34

[ISG2015]

А какой конкретно GPRS? TCP, UDP, почта, WEB? Только отправка данных, или двухсторонний обмен? Есть ли потребность в минимизации трафика?

Все пока на стадии инициации проекта. Толком еще не расставлены акценты. Все еще в виде черновика и мутных планов.
Но точно необходимо будет:

1. Технология будет похожа на клиент-серверную организацию;
2. Скоррее всего на стороне сервера будет статический IP;
3. Минимальный трафик;
4. Обмен данными двухсторонний, но есть мысли о том чтоб клиенты получали информацию читая данные из тиблиц БД на сервере, отправляли данные записывая данные в БД на сервере. Таким образом нам не нужно будет работать напрямую от сервера к клиенту.

В принципе можно поднять на сервере TCP сервер или WEB сервер. Выбор технологии будет связан с клиентской стороной. На стороне клиента(тов) будут SIM900 и Ethernet модули.

Сообщение отредактировал ISG2015 - May 7 2015, 05:36

[p_kav]

Всё это описано в документе "SIM900 TCPIP Application Note", с примерами команд.
Думаю, вам подойдет прозрачный режим - настроили модуль, подняли соединение, и общаетесь с сервером напрямую, посылая и принимая данные из сокета прямо с последовательного порта. Если при этом будет нужна обработка звонков и SMS, то можно подключить контакт RI к контроллеру, и модуль будет информировать о входящих SMS и звонках импульсами на этом контакте.

[ISG2015]

Всё это описано в документе "SIM900 TCPIP Application Note", с примерами команд.
Думаю, вам подойдет прозрачный режим - настроили модуль, подняли соединение, и общаетесь с сервером напрямую, посылая и принимая данные из сокета прямо с последовательного порта. Если при этом будет нужна обработка звонков и SMS, то можно подключить контакт RI к контроллеру, и модуль будет информировать о входящих SMS и звонках импульсами на этом контакте.

Да, спасибо.

Что имею на сегодня:
1. Поднял на сервере с статическим адресом от провайдера TCP-сервер.
2. AT командами установил на модеме SIM900 соединение с сервером.
3. Успешно попробовал отправлять данные от модема к серверу.

Но все это верхушка айсберга. Не понимаю совершенно, как поддерживать это "сессию" в актуальном состоянии, как обрабатывать ошибки, отваливания, и вообще как следить за линком?

Подскажите, каким вы пользуетесь софтом для работы с АТ командами? Каким для работы с СОМ портом?
Попробовал "Terminal.exe" и "COM Port Toolkit 3.9". Мне показались они не оч. подходящими.

Спасибо!

Сообщение отредактировал ISG2015 - May 8 2015, 07:08

[p_kav]

PuTTY приличный терминал для COM-порта.

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

Насчет поддержания сессии - рекомендую определить на сервере какую-то последовательность, на которую он просто отвечает и не выполняет никаких действий. например, если отправить на сервер "NOP", сервер вернет "NOP OK". SIM900 должен отправлять этот "NOP" раз в минуту и если получает ответ, значит сессия жива, иначе её надо переустановить. Суть в том, что на механизм TCP надеяться не следует - если в течение какого-то времени по TCP-сессии не передается никаких данных, многие файрволы просто забывают о ней никак не уведомляя клиент и сервер, и оба шлют данные в никуда.

[ISG2015]

Спасибо за советы.

Еще не очень понимаю, как именно посмотреть статистику по расходу трафика на стороне модема? Как понять сколько трафика расходует SIM900 в GPRS режиме в данных конкретных обстоятельствах?

По поводу "NOP" - "NOP OK" это наверное правильно, ведь если на серверной стороне я еще смогу понять что нет линка с конкретным клиентом средствами самого сервера, то на клиенте все далеко не так очевидно. Хотя вообще чайник ,могу и ошибаться.

Сейчас у меня при простое модема с поднятой сессией отваливается "PDP DEACT"

[p_kav]

Счетчиков трафика в модуле я не нашел, но я не вижу в них смысла - вы же сами принимаете и передаете все данные и сам знаете сколько передали и приняли. Есть, конечно, оверхед протокола TCP, но им можно пренебречь т.к. оператор всё-равно округлит количество данных, переданных по каждой GPRS-сессии до сотен килобайт в большую сторону, поэтому считать байты, как было на GPRS-WAP смысла нет.

[kan35]

Можно пойти пацанским путём: использовать PPP и внешний tcp стек, благо нынче и железа подходящего полно и софт есть
например lwIP и STM32 и любой модем включая проводные))

[GeGeL]

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

Гораздо проще использовать UDP. На сервере держите всего один сокет, при получении пакета от клиента проверяете контрольную сумму, сохраняете данные в базе, возвращаете КС на IP/порт отправителя.
Алгоритм клиента: если есть новые данные, поднимаете GPRS, отправляете данные и КС, ждете ответа 2-3 сек, если нет, то повторяете 3-5 раз. После получения подтверждения или исчерпания попыток рвете GPRS (если сеансы реже 5-10 мин), или оставляете, если чаще.
Преимущества: не нужна поддержка открытой ТСП-сессии, нет процедур конекта/дисконекта, гарантийность доставки и таймауты организованы под задачу, а не универсал. Т.к. у вас статический IP на сервере, не надо ресолвить доменное имя. Трафик, как минимум, в 1.5 раза меньше, чем в случае с ТСП.
С помощью OpenCPU/EAT это реализуется за час. И, кстати, почему Вы не хотите использовать EAT? Если нет желания изучать все команды, можете использовать всего одну - отправку данных в виртуальный порт. И один обработчик - получение данных с него. А дальше отсылайте АТ-команды, и получайте ответы так же, как и в случае с внешним процессором. И надежней, и дешевле, и код переносимый будет.

Что касается канала сервер-диспетчер, то тут как угодно, например, SQL.

[p_kav]

Не соглашусь про разрыв GPRS - оператор округлит объем в большую сторону и 20 байт превратятся в 100 килобайт.
Про UDP тоже не всё так просто. Если сервер захочет передать модулю какие-то данные не сразу после прихода сообщение от модуля, а в произвольное время, то не факт, что они дойдут т.к. файрвол провайдера может просто забыть об этой сессии. Клиенты мобильных операторов сидят за NAT, адресов не так много, поэтому неактивные сессии там устаревают и сбрасываются очень быстро. С TCP же понятно подключен ли в конкретный момент конкретный модуль к серверу и дошло ли сообщение. Если начать реализовывать все эти проверки доставки на UDP, то в конце концов просто заново изобретешь TCP.

[GeGeL]

разрыв GPRS - оператор округлит объем в большую сторону

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

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

По условию ТС сервер поднят на белом IP. Поэтому, независимо от того, какой IP назначен сисопом модулю, первый же и любой пакет, отправленный с модуля на сервер в любое время, инициирует фаервол провайдера, и будет выпущен наружу. Т.к. по определению на серверной части нет фаервола, то он будет доставлен. NAT со стороны провайдера будет инициализирован, и сервер имеет около 3 минут на ответ. По истечение этого времени NAT провайдера закроет соединение, и сервер никак не достучится до клиента, аж до следующей активности клиента. Если передачу "клиент-сервер" по условию задачи инитит только клиент, то все ОК. Если требуется возможность активации клиента со стороны сервера, то, как по мне, проще сделать это входящем звонком клиенту (при разумном количестве клиентов и редких случаях, например, конфигурирование клиента), чем держать все время отрытую TCP-сессию.

Если начать реализовывать все эти проверки доставки на UDP, то в конце концов просто заново изобретешь TCP.

Именно к этому я и веду: многие разработчики, со студенческой скамьи запомнив, что TCP обеспечивает гарантированную доставку, понятия не имеют, как на самом деле это происходит. Более того, в большинстве случаев не могут повлиять на таймауты переотправки, закрытия и т.п. сокета, определяемые внутренними настройками TCP-стека. Известно: универсальных вещей хороших не бывает. Если вы сделаете свой слой гарантийной доставки и контроля под задачу над UDP, то он будет однозначно лучше штатного TCP. Но обычно лень побеждает, и придумываются оправдания.

[BIOlinq]

Под SIM900 и AVR например есть готовые опенсорсные библиотеки, которые умеют TCP, у вас что будет подключено к SIM900? МК?

[p_kav]

Под SIM900 и AVR например есть готовые опенсорсные библиотеки, которые умеют TCP

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

[ISG2015]

Можно пойти пацанским путём: использовать PPP и внешний tcp стек, благо нынче и железа подходящего полно и софт есть
например lwIP и STM32 и любой модем включая проводные))

Не понял. А для чего именно РРР и внешний стек? Мне интересно использовать GPRS так как во многих местах и случаях это единственный способ связаться с сервером.
lwIP и STM32 это как раз сейчас в работе, но это канал связи там где есть инет.

Гораздо проще использовать UDP. На сервере держите всего один сокет, при получении пакета от клиента проверяете контрольную сумму, сохраняете данные в базе, возвращаете КС на IP/порт отправителя.
Алгоритм клиента: если есть новые данные, поднимаете GPRS, отправляете данные и КС, ждете ответа 2-3 сек, если нет, то повторяете 3-5 раз. После получения подтверждения или исчерпания попыток рвете GPRS (если сеансы реже 5-10 мин), или оставляете, если чаще.
Преимущества: не нужна поддержка открытой ТСП-сессии, нет процедур конекта/дисконекта, гарантийность доставки и таймауты организованы под задачу, а не универсал. Т.к. у вас статический IP на сервере, не надо ресолвить доменное имя. Трафик, как минимум, в 1.5 раза меньше, чем в случае с ТСП.
С помощью OpenCPU/EAT это реализуется за час. И, кстати, почему Вы не хотите использовать EAT? Если нет желания изучать все команды, можете использовать всего одну - отправку данных в виртуальный порт. И один обработчик - получение данных с него. А дальше отсылайте АТ-команды, и получайте ответы так же, как и в случае с внешним процессором. И надежней, и дешевле, и код переносимый будет.

Что касается канала сервер-диспетчер, то тут как угодно, например, SQL.

Спасибо за совет.
Во-первых: мне нужно не проще а надежнее, стабильнее и прозрачнее. То есть, канал связи обязательно должен быть построен с использованием правильной архитектуры. Если не будет хватать знаний и навыков - будем вникать. Алгоритм клиента планируется в принципе иной. Я хочу отправлять и принимать данные на клиенте через БД на серверной стороне. Таким образом что для отправки данных клиент пишет в БД, а для получения информации ее (БД) читает. С другой стороны сервер работает с этой же БД. Таким образом клиент работает не с сервером а с БД на сервере. Это важно.
А вот трафик да, тут нужно конечно думать. Сегодня пришло письмо от оператора связи в котором мне дали понять что я не смогу в режиме "онлайн" мониторить расход трафа. Только в начале месяца за прошлый статистика.
OpenCPU/EAT хорошие и нужные вещи, но наверное не в нашем случае. Для нас GPRS это канал связи, а модем портал для работы в этом канале. Не хочется усложнять.

[CADiLO]

>>> Сегодня пришло письмо от оператора связи в котором мне дали понять что я не смогу в режиме "онлайн" мониторить расход трафа. Только в начале месяца за прошлый статистика.

Так небось это на стандартный "разговорный" пакет. Спросите у оператора пакет для M2M - они специально ориентированны на передачу данных и мониторинг трафика должен быть.

Примеры таких пакетов у нас

http://www.kyivstar.ua/ru/ck-238/business/...s/messages/m2m/
http://corp.mts.com.ua/rus/telematic_tariff.php

и в России

http://www.corp.mts.ru/telematika/tariffs/telematika/

Гибкие условия тарификации Интернет - трафика:
оплата по факту потребления - для небольших объемов передаваемых данных;
пакеты GPRS трафика – для более интенсивного обмена данными;
безлимитные опции;
округление GPRS трафика 1 Кбайт - вы не платите за трафик, который не потребляли;


И если будете делать свой внешний стек, то тогда посмотрите в сторону 3G модуля SIM5350.
Там нет встроенного TCP/UDP стека, зато умеет работать в два потока IP/V4 и IP/V6 в любой комбинации.
Идеальный модуль под внешний стек - быстрый и для 3G недорогой.

•IPV4/IPV6 Dual protocol stack
•Mutil-PDP
•Secondary PDP active

[ISG2015]

Смотрю много решений с 2мя SIM-картами. Используя одни АТ команды для TCP коннекта, необходимо будет как-то со стороны внешнего процессора переключать карточки?

И если будете делать свой внешний стек, то тогда посмотрите в сторону 3G модуля SIM5350.
Там нет встроенного TCP/UDP стека, зато умеет работать в два потока IP/V4 и IP/V6 в любой комбинации.
Идеальный модуль под внешний стек - быстрый и для 3G недорогой.

Почитаю о нем. Не совсем понял, что значит нет встроенного TCP/UDP стека и зачем мне два потока IP/V4 и IP/V6 в любой комбинации?
А вот поддержка 3G это здорово. В любом случае это будущее.

[p_kav]

А я бы не рекомендовал 3G для автономных и удаленных устройств. Покрытия 3G гораздо хуже 2G, поэтому энергопотребление будет намного выше, а также будут спонтанные переключения между 3G и 2G, во время которых связь будет теряться. 3G нужен только там, где требуется передавать большие объемы данных.

[GeGeL]

Во-первых: мне нужно не проще а надежнее, стабильнее и прозрачнее.

Так это тесно коррелирует: чем оно проще, тем все остальное перечисленное.

OpenCPU/EAT хорошие и нужные вещи, но наверное не в нашем случае. ... Не хочется усложнять.

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

Алгоритм клиента планируется в принципе иной. Я хочу отправлять и принимать данные на клиенте через БД на серверной стороне. Таким образом что для отправки данных клиент пишет в БД, а для получения информации ее (БД) читает. С другой стороны сервер работает с этой же БД. Таким образом клиент работает не с сервером а с БД на сервере. Это важно.

Несколько раз перечитал, но так и не понял. Понятно, что имеется мобильный клиент с GSM-модулем. Понятно, что имеется постоянно работающий сервер с белым IP и БД на борту. Еще имеется диспетчер, подключенный к серверу, но это не важно.
Вопрос в том, кто инициирует обмен "клиент <> сервер"? В варианте с UDP клиент может первым послать на сервер пакет в любое время, и затем обмениваться данными с БД сервера. Если же обмена нет длительное время (>3 мин), то сервер не сможет первым связаться с клиентом и должен дождаться пакета от клиента. Если это допустимо по условиям задачи, то сохраняйте в БД сервера необходимые данные для клиента (переданные диспетчером), и они будут доставлены клиенту при первой же его активности.
Кроме того, "расшевелить" клиента также можно входящим звонком: после звонка клиент тот час отправляет пакет на сервер, тем самым инициируя обмен по запросу диспетчера, и забирает с сервера заготовленные для него данные.

[x893]

GSM модулю по барабану сколько карт - их можно внешним процессором переключать, только првильные параметры GPRS надо давать по IMSI коду. Модуль GSM можно любой использовать - главное что бы работал (не все модули одинаково хороши). БД и прочая лабуда для GSM - как рыбе зонтик.
Можно TCP/UDP, но мастера php/aspx/... могут и через http всё реализовать - разницы нет.
Вообще не понятно в чем проблема - примеров и кодов готовых - тонна.

[ISG2015]

Если же обмена нет длительное время (>3 мин), то сервер не сможет первым связаться с клиентом и должен дождаться пакета от клиента.

Доброе! Сервер НЕ будет связываться с клиентом вообще. Я хочу отказаться от модели в которой сервер общается с клиентом напрямую.
Клиент передает данные на сервер записывая информацию в БД. Получает информацию читая из БД.
БД тут только для некоторого удобства и простоты, как бы это не казалось странным на первый взгляд.

Я на самом деле советуюсь с вами, и далеко не гуру в принципе.

[ISG2015]

GSM модулю по барабану сколько карт - их можно внешним процессором переключать, только првильные параметры GPRS надо давать по IMSI коду. Модуль GSM можно любой использовать - главное что бы работал (не все модули одинаково хороши). БД и прочая лабуда для GSM - как рыбе зонтик.
Можно TCP/UDP, но мастера php/aspx/... могут и через http всё реализовать - разницы нет.
Вообще не понятно в чем проблема - примеров и кодов готовых - тонна.

Я и не говорю что проблема. Но очевидно что не все так просто.
На данный момент у меня есть понимание многих из ранее заданных вопросов. Есть и темные "места". Вот например я не понимаю на сколько это правильно/разумно и эффективно держать открытой TCP сессию открытой долго. Если таких сессий будет тысячи на одном сервере ,то как это отразится на работе системы? Вопросы ламерские, но ответы на них для меня не столь очевидны.

[p_kav]

Количество никак не отразится, если памети в нем не 128 Мб. Сервер напрягается по количеству пакетов в секунду и запросами к БД. Чтобы существенно напрячь его по трафику нужны миллионы клиентов, а вот как его напрягут запросы к БД зависит исключительно от правильности написания этих запросов программистами и правильности настройки СУБД сисадмином. В целом, VPS за 5 долларов в месяц с 512 Мб памяти должен без проблем вытянуть тысяч 5 клиентов, присылающих информацию раз в минуту, если сервеную часть писали нормальные программисты.

[RadikX]

Количество никак не отразится, если памети в нем не 128 Мб. Сервер напрягается по количеству пакетов в секунду и запросами к БД. Чтобы существенно напрячь его по трафику нужны миллионы клиентов, а вот как его напрягут запросы к БД зависит исключительно от правильности написания этих запросов программистами и правильности настройки СУБД сисадмином. В целом, VPS за 5 долларов в месяц с 512 Мб памяти должен без проблем вытянуть тысяч 5 клиентов, присылающих информацию раз в минуту, если сервеную часть писали нормальные программисты.

Открытые TCP сессии однозначно зло! Особенно если клиенты цепляются по GPRS. Клиент должен подключиться, сделать свое дело и отпустить сервер. Когда клиентов больше 1000-1500 начинает очень заметно ощущаться "мертвые души" соединений, если, конечно, сервер сам не будет по таймауту неактивности их закрывать. Дело не в трафике, а в количестве одновременно существующих соединений.

[p_kav]

Да ну я бы не сказал. Поднимал сервер на 5000 TCP-соединений (GPS-трекеры), проблем именно с соединениями не было, в базу тоже всё всё успевало писаться.
Думаю, запариваться над этим на старте проекта не стоит. Если клиентов станет действительно очень много, тогда денег уже будет достаточно, чтобы распределить прием данных на несколько серверов при помощи, например, DNS.

[GeGeL]

Помнится, ТС заказывал надежнее, стабильнее и прозрачнее. А если еще и инициализация соединения "клиент <> сервер" нужна только со стороны клиента, то тут сам бог велел использовать UDP, сразу решается масса проблем.
В клиенте отпадает необходимость TCP-конекта/реконекта и проверять, не отвалился ли сервер. Нет постоянного расхода трафика на KeepAlive.
В модуле на старте:
- инициируете GPRS;
- создаете UDP-сокет;

Когда есть данные к отправке, упаковываете их в пакет, сопровождая crc и просто отсылаете на сервер, запоминаете crc, запускаете таймер и счетчик повторов. При истечении таймаута дублируете пакет. По исчерпании попыток пингуете 8.8.8.8. пару раз. По истечении таймаутов ресетите модуль.
При получении данных с сокета проверяете: если от 8.8.8.8, то пинг ОК, если с IP сервера, то сверяете crc в ответе с запомненной, если ОК, то завершаете.
Ответ сервера содержит crc полученных данных, данные для клиента, и общее crc пакета.

На сервера запускаете легковесный демон, написанный на голом С + легковесная С-библиотека SQL. В цикле опрашивате единственный открытый UDP-сокет. Если получен пакет, сверяете crc, извлекаете данные из полей пакета и пишете в БД, затем читаете с БД данные для этого клиента, распихиваете по полям, отдельно возвращаете crc принятого пакета, и отправляете на IP-порт, откуда пакет пришел.

Диспетчер работает с серверной БД обычным способом, тут ничего сложного нет.

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

[ISG2015]

Да, пожалуй соглашусь: UDP это то что мне подходит.
А зачем пинговать 8.8.8.8 ? Ведь если мне не отвечает сервер, то все остальное мне фиолетово так как нет канала связи. Да, есть инет, но сервак-то "валяется")

У меня статический адрес у сервера. Но он в силу разн. причин и обстоятельств может быть изменен. У клиента же зашит один фиксированный адрес. Может быть правильнее клиенту записывать/указывать адрес через некоего посредника? Люди для сайтов покупают доменное имя, и таким образом абстрагируются от всех вопросов с IP адресами.

Переписал сервер для работы с UDP сокетом. Модем SIM900 при создании сессии указываю UDP вместо TCP. Сутки почти модем отсылает с периодом в 20 с небольшой пакет на сервер. Не отваливается. С TCP было по-другому: сессия отваливалась в течении небольшого промежутка времени.

[rx3apf]

Люди для сайтов покупают доменное имя, и таким образом абстрагируются от всех вопросов с IP адресами.

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

[p_kav]

ISG2015
Можно зашить в EEPROM 3 бесплатных доменных имени и при подключении перебирать их по очереди, а в случае проблем с каким-то из них просто отсылать клиенту информацию о новых доменах, чтобы он у себя в памяти их обновил.

А TCP-сессия отваливалась именно при отправке данных каждые 20 секунд? Очень странное поведение.

[GeGeL]

А зачем пинговать 8.8.8.8

Дело в том, что нет доверия к самому GSM-модулю: внутренний стек или GPRS может глюкнуть, тест состояния будет ОК, но пакеты не будут даже выходить. Контроллер будет считать, что умер сервер, и ждать, ситуация зациклиться. Если же после нескольких неудачных попыток получить ответ сервера пробовать пинговать что-то гарантийно работающее, то сразу ясно: причина в модуле или в сервере. И если в модуле, то можно перезапустить.
Причем 8.8.8.8 можно даже не пинговать, а отсылать в 51 порт UDP-пакет с DNS-запросом доменного имени, заведенного для вашего сервера, а по получению UDP-ответа парсить датаграмму и извлечь IP.
Сам запрос шаблонный: захватите снифером с РС и запишите в виде сonst в контроллер. С поиском IP в ответе сложнее: он не по фиксированному смещению, и есть два варианта упаковки. Если не лень, посмотрите мой ассемблерный код по ссылке выше и переведите на С. Или, лучше, почитайте rfc по DNS и напишите парсер сами.
Таким образом, убиваете сразу двух зайцев: убеждаетесь, что модуль не висит, и получаете новый IP сервера, если он изменился. Т.е. можно даже поднять сервер на динамическом IP c использованием DynDNS (правда, он сейчас полностью платный стал).

[ISG2015]

GeGeL, спасибо за советы. Да, может и стек в симкоме глюкнуть, и GPRS. Контроллер может ошибочно считатьчто умер сервер. Пингуя 8.8.8.8 (или не пингуя а запрашивая адрес, как Вы описали) можно убедиться в том что именно "висит", но при всем при этом выход из ситуации только один: перезагрузка модуля.
Но пинговать 8.8.8.8 безусловно может оказаться полезно, так как перегружать модуть бесконечно нет смысла. Нужно обдумать логику работы модуля, особенно если учесть, что у меня 2 SIM-карты.

Сейчас озадачился написанием "стека" АТ команд для модема. Как я погляжу народ все делает на задержках (функции Delay под различными соусами), но я думаю это не айс. Не хочется изобретать велосипед, но чувствую, что буду вынужден)

[CADiLO]

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

[ISG2015]

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

С периодом 20с отправлял 2е суток (UDP слот). Сейчас поставлю 60 с.

Сообщение отредактировал ISG2015 - May 18 2015, 07:03

[CADiLO]

Думаю что перепроверить с разным временем лучший выход.

У нас, у Киевстара, нет такого глюка, а у Лайфа - 3-5 минут нет данных и все - большой шанс отправить "в никуда"

[ISG2015]

Поставил на компьютер программу снифер/анализатор сетев. протоколов "Wireshark". Отправляю по UDP 1 байт. Получаю: "Frame Length: 60 bytes (480 bits)" о_О

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

[p_kav]

Так провайдер тарифицирует трафик на 3 уровне, весь фрейм отбрасывается ещё на оборудовании оператора, остается только внутренность IP-пакета. Хотя, этот момент я бы уточнил у оператора, но весь фрейм 2 уровня целиком уж точно никто не тарифицирует.

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

Сообщение отредактировал p_kav - May 18 2015, 09:01

[GeGeL]

Получаю: "Frame Length: 60 bytes (480 bits)"

Это проблема Ethernet - кадр дополняется нулями. В вашем случае внутреннего стека GSM-модуля оверхед будет 24 байта на пакет (на IP+UDP заголовки). Раньше они тарифицировались, сейчас не могу сказать, тем более по каждому оператору.

я в месяц попадаю на 1 Мбайт Что-то жирновастенько

Эдуард, это то, о чем я писал. И это только начало...

[ISG2015]

Эдуард? о_О

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

[CADiLO]

>>> Эдуард? о_О

Да. А шо?

Как мне сказал начальник Кемеровского ОРТПЦ
- Днепропетровца узнать легко - "шо", "га" и "тю" одновременно в лексиконе есть только там.

К сожалению это наша действительность - волкИ хотят "еды".

[GeGeL]

Эдуард

Это была реплика к CADiLO в продолжение нашей старой дискуссии.

[RadikX]

Сейчас озадачился написанием "стека" АТ команд для модема. Как я погляжу народ все делает на задержках (функции Delay под различными соусами), но я думаю это не айс. Не хочется изобретать велосипед, но чувствую, что буду вынужден)

Правильно думаете. Велосипед давно придуман - switch, описывающий состояния автомата. На Delay делают первокурсники - тошно видеть такое от многоопытных дядек.

[p_kav]

То есть отправляем команду, и ждем пока не получим OK или не истечет таймаут, а дальше анализируем вывод команды или обрабатываем ситуацию таймаута?
А как реализуют обработку незапрошенного вывода? Например, модуль выводит текст длинного SMS, и в этот момент на него позвонили и он выводит RING прямо в середине текста, как это обрабатывают многоопытные дядьки?

[CADiLO]

AT+GSMBUSY=1
-прочесть SMS
AT+GSMBUSY=0

это так - навскидку....


второй вариант
завести RI на контроллер, а URC RING отключить AT+CFGRI


кстати интересный момент - надо будет специально проверить
я что-то не видел чтобы в текст SMS вклинивались URC

[ISG2015]

Сегодня таки выяснил какие накладные расходы на передачу 1 байта поверх сетей GSM (Life Украина) по технологии GPRS:
8 байт на UDP заголовки и 20 байт на IP. Итого 28 байт. Ну это уже нормальненько так
Остается надеяться, что подобного рода расклады с тарификацией и у других операторов.

[p_kav]

CADiLO
Так там же куча всяких URC может приходить, про SMS, про регистрацию в сети, про выход питающего напряжения за пределы... Их что, все отключать перед каждым запросом и включать после него? Хотелось бы услышать совет из практики.

ISG2015
А SIM-карту в устройство будет вставлять пользователь, или вы сами? Если пользователь, то у какого-то оператора наверняка найдется какой-то тариф с дорогими разговорами и дешевым трафиком. У меня GPS-трекер с SIM-картой Мегафон и тарифом "Мегафон-Онлайн" уже года три на 300 рублях катается.

[CADiLO]

Насколько я помню, вывод текста SMS это тело команды и до ОК прервано быть не может.
Я перепроверю конечно, но скорее всего что в текст SMS подмешаться URC не может.

[p_kav]

CADiLO
А остальные команды? AT+CNETSCAN, AT+CENG, AT+HTTPREAD, AT+CIPGSMLOC, которого ждать надо пару секунд? Во все не могут пролезть? На сколько я помню по экспериментам с SIM908, пролезают ещё как (правда, не помню версию прошивки, на которой тестировал). Если бы не пролезали, алгоритм конечного автомата управления модулем можно было бы очень упростить.

[ISG2015]

Подскажите, где взять прошивку для SIM900R? Мне нужно сбросить модем в заводские настройки. Спс!

UPD
Вопрос снимается, разобрался.

Сообщение отредактировал ISG2015 - May 19 2015, 17:22

[GeGeL]

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

Вот как люди умудряются усложнять себе жизнь... Я давно работаю с Quectel ОЦПУ, и никогда не сталкивался с проблемами в этом плане. Конечно, при ожидании ответа на АТ-запрос может прийти левый URC, но ведь все равно все должно проверяться, перед тем, как парситься. Т.е. одной state-машины недостаточно, надо каждые данные парсить и проверять на соответствие ожидаемым. Для этого используется strstr. Ради интереса посмотрите код Quectel RIL (от производителя). Там обработчик события UART с подключаемыми парсерами, которые формируют callback-и.

Честно, тут я категорически не согласен со Stanley - он пошел на поводу юзерофильности, и потерялась изящность и прозрачность предыдущих версий ОЦПУ с опросом getEvent в цикле. Теперь фиг поймешь, в контексте какой нити выполняются callback-и и какие данные защищать мутексами. Но зато школьники тащутся - привычная и уютная среда...


Не заморачивайтесь на абстракциях. Просто попробуйте сесть, сосредоточиться и ясно представить, как реально будет идти обмен с модулем, и предвидеть по возможности все ситуации, а также предусмотреть вывод отладочного лога с указанием номеров строк и параметров.
ПС: АТ-ответы и URC никогда не разрываются другими URC - все становится в очередь. Любой ответ и URC, как правило, имеет префикс, указывающий на его принадлежность.

[CADiLO]

О!

>>>Не заморачивайтесь на абстракциях.

Согласен 100%

Бритва Окама - самое то: "Не надо изобретать сущностей сверх необходимого"

[ISG2015]

Подскажите ,а как идентифицировать оператора на SIM-карте? Запрашивать номер, вырезать первые цифры и по этим цифрам распзнавать?
Может быть есть элегантнее способ!?
Спс!.

[RadikX]

AT+COPS =0,2 // Отображение название оператора в цифровом виде
AT+COPS? // Чтение ID оператора

25001: MTS
25002: Megafon
25020: Tele2
25039: Utel
25099: Beeline

Если поискать, то можно найти полный список операторов мира с их кодами. Список не такой уж и большой.

[ISG2015]

А для Украины MNC кодами не поделится никто?

Пишу свою реализацию работы с модемом. Наметилось несколько вопросов:
1. При инициализации UDP сокета, команда "AT+CIFSR" возвращает локальный адрес, но не возвращает финального "ОК"! Я анализирую ответ от модема и считаю, что команда выполнена успешна именно по этому "ОК". Получается как то не але Приходится городить что то типа такого:

Код

if ( SearchRespondSIM900( "OK" ) || SearchRespondSIM900( "." ) )

Точка является разделителем в IP адресе, но вполне может встретиться еще где-то.

2. Какое время установки сессии? У меня получается зарегистрироваться в течении 10,55 сек. с момента подачи питания на модем и 2,28 сек. если модем уже был включен.

Сообщение отредактировал ISG2015 - May 21 2015, 16:04

[RadikX]

1.
Для Украины код MCC = 255, а идентификатор MNC присваивается в порядке регистрации:
- MNC:01 Ukrаinian Mobile Communication, UMC;
- MNC:02 Ukrainian Radio Systеms, URS;
- MNC:03 Kyivstаr GSM;
- MNC:04 Internаtional Telecommunications Ltd;
- MNC:05 Gоlden Telecom;
- MNC:06 Astelit;
- MNC:07 Ukrtelecom;
- MNC:21 CJSC - Telеsystems of Ukraine.
2.
AT+CIFSR является неподтверждаемой (без OK), и таких команд достаточно много. Ищите блоками заканчивающимися на концевик 0x0D 0x0A, большинство из них имеют префикс для распознавания ("+CREG:", например). Я пришедшие блоки маркирую в отдельном буфере и ищу ответы уже по нему.

Прототип функции обработки команд:
TStruct_OpResult AtOp_Template(TStruct_AtCommand *MyAtCommand, uint8_t CmdAnswer, bool IsUnsolicited, uint8_t RepeatCmd, uint16_t RepeatAnswer, bool ClearAnswerBuf);

Пример для AT+CIFSR:

AtOp_Template(AtCommand, cCmdData, TRUE, 3, 30, TRUE); - Ищем данные без префикса, подтверждающий OK не требуется, 3 повтора при неответе, ищем ответ 30 циклов, очистить перед посылкой буфер ответов;

3.
Регистрируется у вас долго, но это зависит от оператора.

[ISG2015]

RadikX, спасибо!
1. Не хватает "Life", UMC это МТС нынешний?

2. На сколько я понял 0x0D 0x0A обрамляются все ответы модема. При этом с 2х сторон непосредственно ответа. Короче мне пока не ясно это дело.


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

[RadikX]

Life - это торговая марка Астелит. а UMC - да, МТС до ребрендинга.
Правила формирований команд и ответов, а также базовый набор АТ-команд подробно описаны в документе "ITU-T Recommendation V.25 ter". В 99% процентах ответы обрамляются с двух сторон "концевиками" 0x0D 0x0A. Есть еще 1% который надо особо разбирать (вроде приглашение ввода при отправке SMS), ну да бог разработчикам протокола судья.

[ISG2015]

Life - это торговая марка Астелит. а UMC - да, МТС до ребрендинга.
Правила формирований команд и ответов, а также базовый набор АТ-команд подробно описаны в документе "ITU-T Recommendation V.25 ter". В 99% процентах ответы обрамляются с двух сторон "концевиками" 0x0D 0x0A. Есть еще 1% который надо особо разбирать (вроде приглашение ввода при отправке SMS), ну да бог разработчикам протокола судья.

Да. Спасибо.
По поводу ответов модема: здорово что обрамляются с 2х сторон 0x0D 0x0A, это и правда замечательно! Я только не совсем понял почему для одной из команд в ответе нет "ОК" Хорошо, это не главная часть ракеты так сказать, разберемся.

[ISG2015]

Доброго времени!
Пилю проект с модемами SIM900R. Столкнулся с такой траблой: время от времени в открытой UDP сессии происходит смена номера порта. То есть, IP не меняется, а вот порт меняется.
Так происходит если модем ничего не передает/принимает в течении приблизительно >8с. Это я так понимаю нормально?
У меня устройство выходит на связь с сервером реже (30с). Сервер отмечает у себя текущий слот с которого обратился модем. К тому времени когда мне необходимо обратится к модему/устройству данные по слоту(порту) устаревают.
Получается мне необходимо все время поддерживать линк отправкой/получением пакета только для того чтоб менялся порт слота?
Спасибо!

Сообщение отредактировал ISG2015 - Aug 26 2015, 18:42

[p_kav]

Модуль тут не при чем, дело в операторе связи.
Они используют NAT, выпуская через шлюз множество клиентов. На всех клиентов получается всего около 64000 портов, поэтому настроены такие жесткие таймауты, чтобы не было ситуации когда все порты заняты.
Проблему можно решить купив услугу "Статический IP" или используя TCP - там таймауты помягче.

Сообщение отредактировал p_kav - Aug 26 2015, 19:01

[ISG2015]

Спасибо! UDP выбрали для сокращения трафика. Буду вникать.

[ISG2015]

1. Подскажите, что если модем SIM900R часто аппаратно перегружается? Ну например в среднем один раз в час. Как это отразится на его работоспособности? Устройство работает круглосуточно, период эксплуатации 5-10 лет.

2. Как правильно "запарковать" модем перед аппаратным перегрузом? Нужно ли предварительно "powerkey" тискать? Обязательно ли за status-ом посматривать?

3. И как таки правильно закрыть GPRS (UDP сессия) ? Сейчас я делаю "AT+CIPSHUT" и жду "SHUT OK"

4. Часто ловлю ERROR на +CSTT= "internet". После "SHUT OK" предыдущей сессии проходит около 18с. Со второй попытки конектится.


Спасибо!

Сообщение отредактировал ISG2015 - Aug 29 2015, 06:49

[CADiLO]

>>>Подскажите, что если модем SIM900R часто аппаратно перегружается? Ну например в среднем один раз в час.

Вопрос - а на пуркуа???
Работает и пусть себе работает - аппаратная перезагрузка это уже самый крайний случай.

[ISG2015]

>>>Подскажите, что если модем SIM900R часто аппаратно перегружается? Ну например в среднем один раз в час.

Вопрос - а на пуркуа???
Работает и пусть себе работает - аппаратная перезагрузка это уже самый крайний случай.

Идея была в том ,что при любой коллизии в GPRS линке - просто перегружать модем аппаратно. Не вдаваясь в подробности так сказать. Если у меня модем подключается к GPRS за 18с то мне легче и проще перегружать все сразу.

[p_kav]

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

И что значит перезагружать аппаратно? По питанию? А может, перед этим попробовать дать ему команду AT+CFUN=1,1 чтобы он сам перезагрузился? Вполне штатный и безболезненный способ.

[GeGeL]

Идея была в том ,что при любой коллизии в GPRS линке - просто перегружать модем аппаратно. Не вдаваясь в подробности так сказать. Если у меня модем подключается к GPRS за 18с то мне легче и проще перегружать все сразу.

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

[ISG2015]

Да, вы правы, что то не так в таком подходе.
Тогда помогите разобраться с тем как:
1. Правильно завершить сессию GPRS (UDP)? Сейчас я выполняю AT+CIPSHUT и жду ОК. Но на форуме читал что ОК может и прийти а сессия еще "висеть".
2. Как запарковать правильно модем? Ведь даже если я буду перегружать модем в исключительных ситуациях, тогда, когда уже ничего другое не помогает, то как бы нужно правильно его подготовить к аппаратному (по-питанию) перегрузу!

А что в вашем случае считается коллизией? Т.е. какой алгоритм определения ситуации, когда надо перезагрузить модем.

А вот что угодно: при попытке подключиться на любую из команд ERROR - перезагрузка, при отправке пакета получили ERROR или PDP DEACT - перезагрузка.

[ISG2015]

3. Еще не совсем понимаю почему модем подключается к GPRS с неправильным APN!? о_О Как тарифицируется все если я неправильно указал APN?

[p_kav]

2. Как запарковать правильно модем? Ведь даже если я буду перегружать модем в исключительных ситуациях, тогда, когда уже ничего другое не помогает, то как бы нужно правильно его подготовить к аппаратному (по-питанию) перегрузу!

Да никак не надо, он при корректном выключении/перезагрузке сам завершает все сессии и посылает оператору сигнал о снятии регистрации в сети. Просто нужно дождаться пока STATUS уйдет в 0.

3. Еще не совсем понимаю почему модем подключается к GPRS с неправильным APN!? о_О Как тарифицируется все если я неправильно указал APN?

Зависит от оператора, у Мегафона даже есть услуга "Интернет без настроек", когда можно писать в APN/Login/Password любой бред. Тарификация так же зависит от честности оператора. также нужно учесть такой момент, что GPRS может устанавливаться, но все пакеты срезаться, а любой HTTP-запрос перенаправляться на специальную страницу оператора.

[ISG2015]

p_kav, а я однако за STATUS совсем не слежу Нужно разбираться с этим делом ,конечно не годится никуда рвать сессии и потом иметь неприятности с опером.

[GeGeL]

Наверное, стоит разделить логику обработки ваших "коллизий" при подключении к GPRS и во время работы. При неудачном подключении сессии как таковой еще нет, поэтому перезагрузка не так страшна. Обычно я запускаю таймер при первой попытке подключения и затем многократно пытаюсь подключиться корректно (без перезапуска). Перезапуск - по таймауту (скажем, 5 минут неудачных попыток). Еще лучше использовать внешний вотчдог на PIC, блокируемый меандром, генерируемым модулем при успешном подключении.
Что касается внештатных ситуаций во время работы, то в случае с UDP - это отсутствие подтверждения от сервера на определенное к-во отправленных пакетов. После этого - отсутствие ответов на несколько пингов или UDP-DNS-запросов, например, google.com, отправленных на 8.8.8.8:53 (запрос формируется по шаблону, ответ детектируется по порту). Тут уже можно деактивировать GPRS и запускать таймер рестарта (тушить меандр) и процедуру запуска GPRS.
Но такая ситуация возможна и в случае кратковременного выхода из покрытия GSM, так что есть смысл дополнительно проверить сигнал, и увеличить (но не бесконечно!) таймаут рестарта в случае слабого сигнала. Где-то так...
А вообще-то хорошо продуманный и практически выверенный алгоритм обработки таких ситуаций - это та "изюминка", которая определит качество работы вашего устройства в целом с точки зрения пользователя.

[ISG2015]

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

Трудно в вами не согласиться. Спасибо!

[glader]

И если будете делать свой внешний стек, то тогда посмотрите в сторону 3G модуля SIM5350.
Там нет встроенного TCP/UDP стека, зато умеет работать в два потока IP/V4 и IP/V6 в любой комбинации.
Идеальный модуль под внешний стек - быстрый и для 3G недорогой.

Вот если б с ним можно было работать по PPP. На команду ATD*99# всегда отвечает ERROR.

[CADiLO]

>>>>Вот если б с ним можно было работать по PPP

SIMCOM_SIM5350_ATC_EN_V1.02 - сделайте поиск PPP по документу

[glader]

SIMCOM_SIM5350_ATC_EN_V1.02 - сделайте поиск PPP по документу

OK. Сигнатура 'PPP' встречается для 4-х команд, причем всегда для вида 'Test command':
1) CGDCONT - сигнатура появляется для пар-ра PDP_type; на деле же, как видно из листинга,
SIM5350 не допускает типа 'PPP' для PDP-context. Второй случай появления этой сигнатуры
в этой команде - это примеры. По всей видимости, SIMCom не подкорректировала мануал;
2) CGQREQ & CGQMIN - на эти 2 команды запроса QOS модуль отвечает ERROR вопреки мануалу;
3) CGEQREQ - аналогично пункту 1).

CODE

AT+CGMR

AT+CGMR
+CGMR: 1231B02SIM5350E
AT+CGDCONT=1,"IP","internet"

AT+CGDCONT=1,"IP","internet"
OK
AT+CGDCONT=?
AT+CGDCONT=?
+CGDCONT: (1-6),"IP",,,(0),(0),(0-1)
+CGDCONT: (1-6),"IPV6",,,(0),(0),(0-1)
+CGDCONT: (1-6),"IPV4V6",,,(0),(0),(0-1)
OK
AT+CGQREQ=?

AT+CGQREQ=?
ERROR
AT+CGQMIN=?

AT+CGQMIN=?
ERROR
AT+CGEQREQ=?

AT+CGEQREQ=?
+CGEQREQ: "IP", (0-4), (0-256000), (0-256000), (0-256000), (0-256000),(0-2), (0, 10-1500, 1502, 1510, 1520), ("0E0","1E2","7E3","1E3","1E4","1E5","1E6","1E1"), ("0E0","5E2","1E2","5E3","4E3","1E3","1E4","1E5","1E6","6E8"), (0-3), (0, 10-150, 200-950, 1000-4000), (0-3)
+CGEQREQ: "IPV6", (0-4), (0-256000), (0-256000), (0-256000), (0-256000),(0-2), (0, 10-1500, 1502, 1510, 1520), ("0E0","1E2","7E3","1E3","1E4","1E5","1E6","1E1"), ("0E0","5E2","1E2","5E3","4E3","1E3","1E4","1E5","1E6","6E8"), (0-3), (0, 10-150, 200-950, 1000-4000), (0-3)
+CGEQREQ: "IPV4V6", (0-4), (0-256000), (0-256000), (0-256000), (0-256000),(0-2), (0, 10-1500, 1502, 1510, 1520), ("0E0","1E2","7E3","1E3","1E4","1E5","1E6","1E1"), ("0E0","5E2","1E2","5E3","4E3","1E3","1E4","1E5","1E6","6E8"), (0-3), (0, 10-150, 200-950, 1000-4000), (0-3)
OK
ATD*99#
ATD*99#
ERROR
OK
ATD*99***1#

ATD*99***1#
ERROR

[CADiLO]

Попробуйте обновиться на 1231B03SIM5350E.
Хотя ответ "PPP" в теле 02 прошивки тоже есть.
Нет отладки под рукою чтобы проверить.

[glader]

Хотя ответ "PPP" в теле 02 прошивки тоже есть.

Техническая спецификация https://www.etsi.org/deliver/etsi_ts/127000...060v090100p.pdf,
описывающая требования для TE - MT взаимодействия над R-опорной точкой для сред пакетной передачи для
IP-базированных сервисов определяет 2 протокола, способных нести IP-кадры над R-точкой: L2 (например,
PPP MCML - RFC 2686) и PPP.

Спецификация определяет также возможную последовательность событий
для внешней программы (TE) и модуля (MT), когда выбран PPP:
после того, как пользователь подписался только на один контекст PDP (типа IP)
- the MT begins in V.25 command state:
- TE -> MT: AT<Packet Domain-specific configuration commands, if required>;
- MT -> TE: OK.
- the TE sends a dial command requesting the Packet Switched service:
- TE -> MT: ATD*99#;
- MT -> TE CONNECT.
- ...
SIM5350 (версия 02) на ATD*99# отвечает ERROR, да и в означенном мануале она отсутствует.
Кто-нибудь связывался с SIM5350 (моделью "быстрой и недорогой") для организации GPRS?