Как связать два gsm модема
модемная связь через GSM-сеть
ПК-модем-мобила-(GSM-сеть)-мобила-модем-ПК
Т.е. получается что-то типа выделенки, но вместо телефонного провода используется GSM-сеть. Может кто-то пытался сделать что-то подобное? Помогите советом возможна ли такая схема в принципе?
ну не выделенка а скорее всего похоже на проводное соединение.
Вы имеете ввиду модем выносной что ли? Ну т.е. обычный компутерный модем? Или встроенный в телефон, сейчас они вроде как почти во всех телефонах есть. Если второе - конечно работоспособно, только в аналоговом режиме там скорости низкие очень, то ли 9600, то ли 14400 бод максимум.
в общем реальная скорость гдето 56Кбит/с скорость скачки 10Кбит/с это на мтс,в общем реальная скорость гдето 56Кбит/с скорость скачки 10Кбит/с это на мтс,
технология GPRS.
технология GPRS.
ну у нас не мтс днём 8 центов ночью 4 цента за метр. путём не сложных расчётов я узнал скрость о которой писал выше, а что касается аналогово соединения так там скорость 9600 и 5 центов за минуту.
Соединение точка-точка, без проблем
Но говорят, что некоторые операторы закрывают эту возможность
Пробовал на ВолгоградGSM (Smarts)
Вот лог для соединения двух модемов FASTRAK (WaveCom)
Один надо инитить сервером, другой клиентом.
Можно Гипертерминалом от любой Вынь
+WIND: 7
at+cpin=1234 // 1234 исправляем на правильный ПИН код
OK
--------- Затем инитим Клиента
at
OK
at+cpin=4507 // Опять ПИН код
// и дальше все то же
OK
+WIND: 4
at+cgatt=1
11.22.0.2 // Получен динамический адрес для второго модема
Все, с этого момента модем перешел в режим данных
и все что вводится с клавы, уходит на сервер по
адресу 11.22.333.44 и выводится на экран
А все, что вводится с клавы сервера появляется
на экране клиента.
Это если с обоих сторон Гипертерминал включен.
Если другое ПО, то его надо настроить на сеть
по КОМпорту. (Гиперы ессно надо выгрузить)
Там еще есть несколько команд инициализации.
Подробности в документе
"AT Commands for IP Connectivity - 002.pdf
for IP Connectivity"
WM_ASW_OAT_UGD_011-002
В одной из моих публикаций было описание материнской платы Mikrotik RBM33G способной работать одновременно с двумя модемами сотовой связи. Ниже я сделаю краткое описание того, как сконфигурировать RouterOS для распределения трафика между двумя lte интерфейсами.
ВАЖНО! Речь в этой статье не идет об агрегации каналов сотовой связи, которую могут делать модемы 6 ( и выше ) категории Lte. Суммирование частот в этом случае происходит внутри модема в автоматическом режиме(или в ручном, если вы вмешались в процесс посредствам АТ команд). Мы же пытаемся объединить 2 модема в один канал, например МТС и Мегафон, что бы они работали одновременно - такая схема может применяться для повышения отказоустойчивости или увеличения пропускной способности.
На тесте я буду использовать два модема Quectel EP06 категории 6 lte . В идеальном случае каждый из модемов будет агрегировать 2 несущие сотового оператора, а материнская плата роутера будет обьединять трафик с 2х модемов в один канал связи.
Кстати сконфигурированную сборку можно приобрести у меня в магазине: ССЫЛКА ЗДЕСЬ
Микротик Роутер ОС очень гибкая операционная система и имеет огромное количество настроек, предложенная мной конфигурация является одной из возможных, но далеко не единственной. Вообще ситуация использования двух шлюзов одновременно для выхода в интернет не является стандартной и имеет множество реализаций, при этом в любом случае будут какие либо костыли, так или иначе портящие общую картину. Но пока не будем о плохом.
Для начала сделаем стандартную настройку Mikrotik RBM33G для выхода в интернет через модем:
- Сбросим конфигурацию до чистой (reset configuration)
- Объединим все LAN интерфейсы в бридж
- Повесим на него адресное пространство 192.168.5.0/24
- Настроим на бридже DHCP сервер
- Сконфигурируем фаервол по желанию
- Настроем NAT для выхода в интернет с нашей подсети
С этого момента у Вас должен быть интернет, который будет работать через один из lte интерфейсов, второй в этот момент будет простаивать.
Далее начинается самое интересное, для того чтобы запустить в работу второй интерфейс нужно выполнить 2 условия: начать делить исходящий трафик между lte1 и lte2, и правильно распределять входящий трафик, что бы наш Mikrotik отвечал с того же интерфейса, с которого пришел запрос.
Первым делом входящий трафик от модемов нужно промаркировать (писать буду в командах для консоли, для тех кто любит WINBOX думаю не составит труда расшифровать):
- ip firewall mangle add action =mark-connection chain=input in - interface =lte1 new-connection-mark=con_LTE1
- ip firewall mangle add action =mark-connection chain=input in - interface =lte2 new-connection-mark=con_LTE2
Метки соединений и маршрутов нужно придумать самостоятельно, это просто название и не содержит в себе ни каких инструкций, вообщем придумывайте как Вам нравится.
Для того что бы роутер мог отвечать через те же интерфейсы, откуда пришел трафик , промаркируем маршруты:
- ip firewall mangle add action =mark-routing chain=output connection-mark=con_LTE1 new-routing-mark=LTE1_rout
- ip firewall mangle add action =mark-routing chain=output connection-mark=con_LTE2 new-routing-mark=LTE2_rout
Теперь необходимо добавить маршруты по умолчанию, в которых будут содержаться наши метки:
ip route add distance=1 gateway=lte1 routing-mark=LTE1_rout
ip route add distance=1 gateway=lte2 routing-mark=LTE2_rout
Для примера я взял разделение с помощью PPC (Per Connection Classifier) , в этом случае группы будут образовываться на основании адреса и порта в заголовке пакета TCP:
/ip firewall mangle add src-address=192.168.5.0/24 action=mark-routing chain=prerouting new-routing-mark =lan-to-LTE1 per-connection-classifier=src-address-and-port:2/0
/ip firewall mangle add src-address=192.168.5.0/24 action=mark-routing chain=prerouting new-routing-mark =lan-to-LTE2 per-connection-classifier=src-address-and-port:2/1
Далее нужно добавить два маршрута по умолчанию для маркированного выше трафика:
/ip route add distance=1 gateway=lte1 routing-mark=lan-to-LTE1
/ip route add distance=1 gateway=lte2 routing-mark=lan-to-LTE2
Вот в принципе и все. Дальше трафик ходит через 2 интерфейса, балансировка закончена.
Можно ли объединить несколько интернет-каналов в один? Вокруг этой темы куча заблуждений и мифов, даже сетевые инженеры с опытом часто не знают о том, что это возможно. В большинстве случаев, объединением каналов ошибочно называют балансировку на уровне NAT или failover. Но настоящее суммирование позволяет пустить одно единственное TCP-подключение одновременно по всем интернет-каналам, например видеотрансляцию так, чтобы при обрыве любого из интернет-каналов вещание не прерывалось.
Существуют дорогие коммерческие решения для видеотрансляций, но такие устройства стоят много килобаксов. В статье описывается настройка бесплатного, открытого пакета OpenMPTCPRouter, разбираются популярные мифы о суммировании каналов.
Мифы про суммирование каналов
Есть много бытовых роутеров, поддерживающих функцию Multi-WAN. Иногда производители называют это суммированием каналов, что не совсем верно. Многие сетевики верят, что кроме LACP и суммирования на L2 уровне, никакого другого объединения каналов не существует. Мне часто доводилось слышать, что это вообще невозможно от людей, которые работают в телекомах. Поэтому попробуем разобраться в популярных мифах.
Балансировка на уровне IP-подключений
Это самый доступный и популярный способ утилизировать несколько интернет-каналов одновременно. Для простоты представим, что у вас есть три интернет провайдера, каждый выдаёт вам реальный IP-адрес из своей сети. Все эти провайдеры подключены в роутер с поддержкой функции Multi-WAN. Это может быть OpenWRT с пакетом mwan3, mikrotik, ubiquiti или любой другой бытовой роутер, благо сейчас такая опция уже не редкость.
Для моделирования ситуации представим, что провайдеры выдали нам такие адреса:
При балансировке на уровне подключений, каждое TCP-подключение идёт через отдельного провайдера .
При загрузке торрентов балансировка на уровне подключений суммирует пропускную способность всех каналов
Такая балансировка позволяет получить суммирование скорости интернет-канала, при использовании множества подключений. Например, если у каждого из трёх провайдеров скорость 100 Мегабит, то при загрузке торрентов мы получим 300 Мегабит. Потому что торрент открывает множество подключений, которые распределяются между всеми провайдерами и в итоге утилизируют весь канал.
Одно подключение всегда будет использовать только один интернет-канал
Это справедливо и для видео-трансляций. Если вы вещаете потоковое видео на какой-то условный Twitch, то балансировка на уровне IP-подключений не даст никакой особенной пользы, так как видео-поток будет транслироваться внутри одного IP-подключения. В данном случае, если у провайдера WAN 3 начнутся проблемы со связью, например потери пакетов или снижение скорости, то вы не сможете моментально переключиться на другого провайдера. Трансляцию придётся останавливать и переподключаться заново.
Настоящее суммирование каналов
Реальное суммирование каналов даёт возможность пустить одно подключение к условному Twitch сразу через всех провайдеров таким образом, что, если любой из провайдеров сломается, подключение не оборвется. Это на удивление сложная задача, которая до сих пор не имеет оптимального решения. Многие даже не знают, что такое возможно!
По предыдущим иллюстрациям мы помним, что условный сервер Twitch может принять от нас видеопоток только от одного source IP адреса, значит он должен быть у нас всегда постоянным, вне зависимости от того, какие провайдеры у нас отвалились, а какие работают. Чтобы этого добиться, нам потребуется суммирующий сервер, который будет терминировать все наши подключения и объединять их в одно.
Суммирующий сервер агрегирует все каналы в один тоннель. Все подключения происходят с адреса суммирующего сервера
В такой схеме используются все провайдеры, и отключение любого из них не вызовет обрыв связи с сервером Twitch. По сути, это особый VPN-тоннель, под капотом у которого сразу несколько интернет-каналов. Главная задача такой схемы — получить максимально качественный канал связи. Если на одном из провайдеров начались проблемы, потеря пакетов, увеличение задержек, то это не должно никак отразиться на качестве связи, так как нагрузка автоматически будет распределяться по другим, более качественным каналам, которые есть в распоряжении.
Коммерческие решения
Эта проблема давно беспокоит тех, кто ведёт прямые трансляции мероприятий и не имеет доступа к качественному интернету. Для таких задач существуют несколько коммерческих решений, например компания Teradek делает такие монструозные роутеры, в которые вставляются пачки USB модемов:
Роутер для видеотрансляций с функцией суммирования каналов
Иногда это выглядит достаточно устрашающе:
Настраиваем OpenMPTCPRouter
Протокол MP-TCP (MultiPath TCP) придуман для возможности подключения сразу по нескольким каналам. Например, его поддерживает iOS и может одновременно подключать к удалённому серверу по WiFi и через сотовую сеть. Важно понимать, что это не два отдельных TCP-подключения, а именно одно подключение, установленное сразу по двум каналам. Чтобы это работало, удалённый сервер должен поддерживать MPTCP тоже.
OpenMPTCPRouter — это открытый проект программного роутера, позволяющего по-настоящему суммировать каналы. Авторы заявляют, что проект находится в статусе альфа-версии, но им уже можно пользоваться. Он состоит из двух частей — суммирующего сервера, который размещается в интернете и роутера, к которому подключаются несколько интернет-провайдеров и сами клиентские устройства: компьютеры, телефоны. В качестве пользовательского роутера может выступать Raspberry Pi, некоторые WiFi-роутеры или обычный компьютер. Есть готовые сборки под различные платформы, что очень удобно.
Принцип работы OpenMPTCPRouter
Настройка суммирующего сервера
Суммирующий сервер располагается в интернете и терминирует подключения со всех каналов клиентского роутера в одно. IP-адрес этого сервера будет внешним адресом при выходе в интернет через OpenMPTCPRouter.
Для этой задачи будем использовать VPS-сервер на Debian 10.
Требования к суммирующему серверу:
- MPTCP не работает на виртуализации OpenVZ
- Должна быть возможность установки собственного ядра Linux
Результат успешной установки сервера.
Сохраняем пароли, они потребуются нам для настройки клиентского роутера, и перезагружаемся. Важно иметь в виду, что после установки SSH будет доступен на порту 65222. После перезагрузки нужно убедиться, что мы загрузились с новым ядром
Видим рядом с номером версии надпись mptcp, значит ядро установилось корректно.
Настройка клиентского роутера
На сайте проекта доступны готовые сборки для некоторых платформ, например Raspberry Pi, Banana Pi, роутеры Lynksys и виртуальные машины.
Эта часть openmptcprouter основана на OpenWRT, в качестве интерфейса используется LuCI, знакомый всем, кто когда-либо сталкивался с OpenWRT. Дистрибутив весит около 50Мб!
В качестве тестового стенда я буду использовать Raspberry Pi и несколько USB-модемов с разными операторами: МТС и Мегафон. Как записать образ на SD-карту, полагаю, не нужно рассказывать.
Изначально Ethernet-порт в Raspberry Pi настроен как lan со статическим IP-адресом 192.168.100.1. Чтобы не возиться с проводами на столе, я подключил Raspberry Pi к WiFi точке доступа и задал на WiFi-адаптере компьютера статический адрес 192.168.100.2. DHCP-сервер по умолчанию не включен, поэтому нужно использовать статические адреса.
Теперь можно зайти в веб-интерфейс 192.168.100.1
При первом входе система попросит задать пароль root, с этим же паролем будет доступен SSH.
В настройках LAN можно задать нужную подсеть и включить DHCP-сервер.
Я использую модемы, которые определяются как USB Ethernet интерфейсы с отдельным DHCP-сервером, поэтому это потребовало установки дополнительных пакетов. Процедура идентична настройке модемов в обычном OpenWRT, поэтому я не буду рассматривать её здесь.
Далее нужно настроить WAN-интерфейсы. Изначально в системе создано два виртуальных интерфейса WAN1 и WAN2. Им нужно назначить физическое устройство, в моем случае это имена интерфейсов USB-модемов.
Так как мои модемы сами выступают роутерами, и сами имеют DHCP-сервер, мне пришлось изменить настройки их внутренних диапазонов сетей и отключить DHCP-сервер, потому что изначально оба модема выдают адреса из одной сети, а это вызывает конфликт.
OpenMPTCPRouter требует, чтобы адреса WAN-интерфейсов были статическими, поэтому придумываем модемам подсети и настраиваем в меню system → openmptcprouter → interface settings. Здесь же нужно указать IP-адрес и ключ сервера, полученный на этапе установки суммирующего сервера.
В случае удачной настройки, на странице статуса должна появится похожая картина. Видно, что роутер смог достучаться до суммирующего сервера и оба канала работают штатно.
По умолчанию используется режим shadowsocks + mptcp. Это такой прокси, который заворачивает в себя все подключения. Изначально он настроен обрабатывать только TCP, но можно включить и UDP.
Если на странице статуса нет ошибок, на этом настройку можно считать законченной.
С некоторыми провайдерами может возникнуть ситуация, когда на пути следования трафика флаг mptcp обрезается, тогда будет такая ошибка:
В этом случае можно использовать другой режим работы, без использования MPTCP, подробнее об этом здесь.
Заключение
Проект OpenMPTCPRouter очень интересный и важный, так как это, пожалуй, единственное открытое комплексное решение проблемы суммирования каналов. Всё остальное либо наглухо закрытое и проприетарное, либо просто отдельные модули, разобраться с которыми обычному человеку не под силу. На текущем этапе развития проект ещё достаточно сырой, крайне бедная документация, многие вещи просто не описаны. Но при этом он всё-таки работает. Надеюсь, что он будет и дальше развиваться, и мы получим бытовые роутеры, которые будут уметь нормально объединять каналы из коробки.
В статье подробно раскрыты расширенные функциональные возможности GSM-модемов производства компании «Телеофис», показано, что этими устройствами можно управлять удаленно, а также можно запрограммировать их под задачи сбора, обработки и передачи информации через GPRS.
GSM-модемы давно стали привычным элементом систем автоматизации и телеметрии. Но пока еще не все интеграторы и пользователи знают, что современные GSM-модемы уже превысили стандартный и знакомый функционал. Рассмотрим новые полезные функции на примере модемов марки TELEOFIS.
Другой часто возникающей проблемой является сложность программирования GSM-модема под задачи сбора, обработки и передачи информации через GPRS. Модемы TELEOFIS имеют встроенный интерпретатор языка Python, что позволяет реализовывать решение задач пользователя непосредственно в GSM-модуле.
Для передачи данных по TCP через GPRS скрипт на языке Python использует встроенный в GSM-модуль TCP/IP-стек, предназначенный для обеспечения простой процедуры управления TCP-соединениями и передачей данных. Управление TCP-стеком осуществляется расширенным набором AT-команд, включающим в себя команды настройки, управления соединениями и др.
Ниже мы рассмотрим подробнее эти и другие возможности новых модемов TELEOFIS.
Кроме обычного режима работы с AT-командами через COM-порт, GSM-модемы TELEOFIS имеют возможность удаленного управления через TCP-соединение в режиме TCPATRUN. При этом логический интерфейс обработки AT-команд подключается напрямую к TCP-соединению.
- оперативно и без выезда на место установки изменять параметры работы модуля;
TCP-соединение с GSM-модемом устанавливается через GPRS и может работать в двух режимах: «Сервер» либо «Клиент». В режиме «Сервер» модем подключается к GPRS и ожидает входящего соединения. В режиме «Клиент» модем сам устанавливает TCP-соединение с заданным IP-адресом.
Для работы с входящими соединениями необходимо подключить к SIM-карте статический IP-адрес, после чего можно будет установить соединение с модемом, например с помощью программы Telnet. В режиме «Сервер» можно использовать авторизацию входящего соединения по логину и паролю.
Рассмотрим процедуру работы с TCPATRUN. Прежде всего необходимо установить соединение GPRS. Для этого контекст PDP должен быть активирован:
Рекомендуется включить автоматический режим установки соединения GPRS:
где параметры – <номер контекста PDP>, <количество попыток соединения>, <тайм-аут между попытками>. Данный режим позволит модему автоматически соединяться с GPRS после включения или перезагрузки.
Далее необходимо настроить TCP-сокет, через который будет устанавливаться соединение:
где параметры – <номер сокета>, <номер контекста PDP>, <размер TCP-пакета>, <таймер разрыва по тишине>, <тайм-аут установки TCP-соединения>, <тайм-аут отправки данных>.
где параметры – <номер сокета>, <номер парсера AT-команд>, <порт для входящих соединений>, <порт назначения для исходящего соединения>, <IP-адрес или имя сервера>, <отображение статуса подключения>, <тайм-аут выполнения команды>, <настройка авторизации в режиме «сервер»>, <количества попыток переподключения к хосту (серверу)>, <время между попытками>.
В установленном TCP-соединении вы осуществляете работу с модемом через AT-команды, как при подключении через последовательный порт.
Таким образом, режим TCPATRUN позволяет удаленное управление, контроль и изменение настроек GSM-модема, что является очень полезной функцией для администратора модема.
Прозрачное соединение с COM-портом в режиме TCPATRUN
По умолчанию на последовательном порту включено управление потоком. Его можно отключить:
Включение режима дистанционной работы по SMS выполняется командой:
где параметры – <добавить/удалить/вывести на экран>, <номер строки>, <тип записи – номер телефона/пароль>, <строка>. Строка, содержащая номер телефона, должна состоять из цифр и может иметь знак «+» в начале и/или знак «*» в конце. Пароль должен содержать 16 символов. Строка в любом случае должна быть заключена в кавычки.
Применяя режим SMSATRUN, вы всегда будете иметь доступ к настройкам GSM-модема и сможете управлять модемом удаленно.
Рис. Интерфейсы взаимодействия Python-скриптов с функциями GSM-модема:
MDM, MDM2 – два логических интерфейса между скриптом и обработчиками АТ-команд; SER, SER2 – доступ к физическим последовательным портам ASC0 и ASC1 соответственно; GPIO – управление линиями ввода/вывода;
MOD – служебные функции; IIC, SPI – реализация интерфейсов IIC и SPI на свободных линиях ввода/вывода
Скрипты пользователя. Встроенный интерпретатор языка Python
GSM-модемы TELEOFIS способны реализовать логику управления без использования внешнего микроконтроллера, путем загрузки пользовательских скриптов на языке высокого уровня Python. Пользовательские скрипты являются текстовыми файлами, которые хранятся в энергонезависимой памяти модема. Память представляет собой файловую систему, которая позволяет записывать и считывать файлы с разными именами на единственном уровне (директории не поддерживаются).
Технически пользовательский скрипт выполняется в виде задачи встроенной операционной системы, которая имеет самый низкий приоритет, чтобы не оказывать влияния на основные функции GSM/GPRS. Пользовательские Python-скрипты могут взаимодействовать с функциями GSM-модема посредством специальных встроенных интерфейсов, описание которых представлено на схеме.
Пользовательские скрипты могут применяться для следующих задач:
Приведем пример простой функции на языке Python, выполняющей управление LED индикатором:
Управление приложением через Интернет, посредством GPRS-модема, позволяет получить доступ к нему в любой точке земного шара по стоимости GPRS-соединения. Стоимость эта рассчитывается исходя из объема переданных данных, а не времени соединения, что позволяет приложению оставаться на связи постоянно и всегда быть готовым к приему и передаче данных.
Однако у технологии GPRS есть и недостаток. Поскольку передача данных осуществляется через сеть Интернет, устройству необходимо иметь собственную реализацию стека протоколов TCP/IP.
GSM-модемы TELEOFIS имеют встроенный TCP/IP-стек, который позволяет пользователям устанавливать соединение с интернет-узлом для обмена данными. Эту функцию можно сравнить с «виртуальным» последовательным соединением между ПО приложения и интернет-узлом. Интересной особенностью является возможность одновременного подключения нескольких соединений, что позволяет пользователю иметь два различных IP-адреса и до шести активных соединений. Каждое соединение может быть связано со своим IP-адресом.
Обычно закрытие соединения CSD происходит в два этапа: сначала GSM-модуль переводится из режима передачи данных в командный режим, а затем посылается АТ-команда «повесить трубку» (ATH). Перевод модуля из режима данных в командный режим осуществляется специальной последовательностью <1,5 секунды пауза>+++<1,5 секунды пауза>. Таким образом, на закрытие соединения уходит примерно 3 с. В случае применения мультиплексного протокола нет необходимости переходить в командный режим, чтобы послать АТH-команду, поскольку ее можно послать по второму виртуальному каналу и завершить соединение практически мгновенно.
Основная причина зависания GSM-модемов – это переподключение между базовыми станциями. Даже если модем установить на неподвижном объекте, он будет периодически менять базовые станции. Дело в том, что модем подключается к конкретной соте не только из-за уровня сигнала, но и из-за ее загруженности в конкретный момент времени. Эта и некоторые другие причины могут привести к зависанию GSM-модема.
Практически во всех сферах применения от GSM-модемов требуется стабильная и надежная работа, при этом модем должен быть доступен в любой момент времени. Для обеспечения надежной работы модема рекомендуется применять режим периодической перезагрузки GSM-модуля.
В модемах TELEOFIS периодическая перезагрузка производится с помощью встроенного в GSM-модуль таймера перезагрузки. Контроллер таймера перезагрузки независим от RF-части GSM-модуля, поэтому в случае зависания последнего контроллер остается работоспособным и перезагружает модем.
Периодическая перезагрузка модема не только уменьшает вероятность зависания GSM-модема, но и позволяет вернуть работоспособность в случае возникновения нештатной ситуации.
В статье мы постарались познакомить читателей с новыми современными функциями GSM-модемов TELEOFIS, которые действительно нужны и дают интеграторам и пользователям дополнительные возможности в работе с оборудованием.
Читайте также: