Как проложить промышленные маршрутизаторы 4g в проекте

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

Как развернуть промышленные маршрутизаторы 4G в проекте "Интернет вещей", чтобы достичь двойных целей - стабильности сети и высокой стоимости? Эта проблема может быть решена путем понимания принципов передачи данных в сети Интернета вещей и общей схемы IP-коммуникаций сети.

Маршрутизация данных от источника к поглотителю является неотъемлемой частью любого крупномасштабного решения для беспроводного зондирования и Интернета вещей (IoT). Неотключаемые и/или мобильные встроенные устройства, используемые в таких сетях с малыми потерями мощности (LLN), всегда сильно ограничены в плане доступной энергии. Поэтому эффективная маршрутизация данных является критически важной для любого долгосрочного устойчивого решения.

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

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

Сети с малыми потерями энергии (LLN) обычно состоят из датчиков, исполнительных устройств и маршрутизаторов, которые взаимодействуют друг с другом по беспроводной связи. Однако, в отличие от датчиков и исполнительных устройств, маршрутизаторы, как правило, не ограничены в ресурсах (в долгосрочной перспективе). Маршрутизаторы, соединяющие LLN с более широкой инфраструктурой Интернета, называются пограничными маршрутизаторами LLN (LBR).

Трафик и потоки данных в сети LLN имеют высокую направленность. Режим может быть определен как трафик "многоточка-точка" (MP2P), трафик "точка-многоточка" (P2MP) или трафик "точка-точка" (P2P). Например, в трафике MP2P информация о зондировании от нескольких зондирующих узлов направляется в интернет-приложения через LBR. Трафик P2MP наблюдается, когда запросы поступают из Интернета (за пределами LLN) и направляются к нескольким узлам на месте через маршрутизаторы LBR и LLN. P2P-коммуникации возникают, когда необходимо отправить управляющую информацию определенному исполнительному механизму или получить информацию о тревоге от определенного датчика.

Целевая группа по проектированию Интернета (IETF) сформировала рабочую группу (WG), чтобы лучше понять требования к энергоэффективным протоколам маршрутизации для таких сценариев применения, как городские сети, системы автоматизации/управления зданиями, системы промышленной автоматизации и домашней автоматизации.

Городская беспроводная сенсорная сеть

Многие проекты, связанные с городским зондированием, позволяют контролировать и отслеживать состояние многих городских ресурсов и окружающей среды. Лаборатория сенсорных городов Массачусетского технологического института (MIT Sensory Cities Lab) реализует несколько проектов, направленных на понимание "городов в реальном времени" для мониторинга "цепочек удаления", в отличие от цепочек поставок товаров, таких как "Мусорная речь" и "Рим в реальном времени". 1 Компания IBM внедрила свои технологии "умного города" в более чем 100 городах по всему миру.

Подобные приложения для городских сетей представляют собой особый вид LLN с уникальным набором требований к беспроводной маршрутизации. Проект Rome Real Time использует агрегированные данные о плотности населения, полученные от операторов мобильной связи, и данные GPS о местоположении общественных автобусов, подключенных через вышки сотовой связи.

Однако создание устойчивого решения, позволяющего собирать, агрегировать и отображать данные, требует внедрения ячеистой сети с низким энергопотреблением, которая может маршрутизировать данные между устройствами, подключенными по беспроводной связи и питающимися от источников питания с низким энергопотреблением. Документ RFC описывает основные функциональные возможности и требования к маршрутизации для городских LLN:

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

- Объединение и разъединение узлов: После этапа инициализации узлы могут присоединяться к сети или покидать ее в любое время. Протоколы маршрутизации также должны уметь справляться с ситуациями, когда вышедший из строя узел может повлиять на общую эффективность маршрутизации или поставить ее под угрозу.

- Периодическое информирование об измерениях: Большинство полевых узлов настроены на передачу показаний через регулярные промежутки времени (ежечасно, ежедневно и т. д.). Расчет и выбор маршрутизации данных может зависеть от полученных данных, частоты отчетов, количества энергии, оставшейся в узле, схемы зарядки узла для сбора энергии или других факторов.

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

- Сообщение о тревоге: Как правило, узлы зондирования могут измерять события, которые классифицируются как тревоги, обычно когда измеренные данные превышают пороговое значение. Маршрут, сообщающий о тревогах, должен быть одноадресным (на LBR) или многоадресным (на несколько LBR).

- Масштабируемость: Протоколы маршрутизации должны быть способны поддерживать развертывание в полевых условиях от сотен до десятков тысяч сенсорных узлов без снижения выбранных параметров производительности ниже настраиваемых пороговых значений.

- Маршрутизация с ограничением параметров: Протокол должен быть способен рекламировать возможности узла (процессор, объем памяти, доступный заряд батареи), которые могут быть использованы для принятия решений о маршрутизации. Живые узлы должны динамически рассчитывать, выбирать и устанавливать различные пути к одному и тому же пункту назначения в зависимости от характера трафика.

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

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

- Поддержка многоадресной и многоадресной рассылки: Протоколы маршрутизации должны иметь схему адресации, которая может поддерживать маршрутизацию к одному полевому устройству (unicast), к совокупности узлов, подписанных на одну группу (multicast), и к множеству узлов, все из которых адресуются одним и тем же IP-адресом (anycast).

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

- Задержка: Протоколы маршрутизации должны поддерживать возможность маршрутизации на основе различных требований к задержке/продолжительности. Городские сети могут терпеть задержки до тех пор, пока время поступления информации пропорционально времени поступления сообщений. (Если время поступает каждые несколько часов, задержка может составлять несколько секунд).

Основные структурные элементы RPL

Суть RPL заключается в организации топологии в виде направленного ациклического графа (DAG), который делится на одну или несколько DAG, ориентированных на пункт назначения (DODAG), по одной DODAG на приемник (см. рисунок). Каждый узел в DODAG (подобно устройству маршрутизации в IoT-решении) имеет ранг узла, определяющий его положение относительно других узлов относительно корня DODAG.

Точный метод вычисления уровня узла RPL зависит от целевой функции (OF) DAG. OF определяет, как метрики маршрутизации, цели оптимизации и связанные с ними функции используются для расчета ранжирования. По сути, OF определяет формирование DODAG. Топология RPL строится с помощью управляющих сообщений, передаваемых в виде сообщений ICMPv6. Три ключевых управляющих сообщения RPL - это:

-Запрос информации DODAG (DIS): DIS запрашивает информационный объект DODAG (DIO) у узла RPL.

- Информационный объект DODAG (DIO): DIO содержит информацию, которая позволяет узлам обнаруживать экземпляры RPL, узнавать об их параметрах конфигурации, выбирать родительские наборы DODAG и поддерживать DODAG.

- Объект целевой рекламы (DAO): DAO используется для распространения целевой информации вверх по DODAG.

Чтобы построить топологию DODAG, узлы могут запрашивать DIO с помощью сообщений DIS или периодически отправлять локальные многоадресные сообщения DIO. Затем узел прослушивает DIO и использует его информацию для присоединения к новой DODAG или поддержания существующей DODAG. Основываясь на информации DIO, узел выбирает родительский узел, чтобы минимизировать стоимость пути к корню DODAG.

в заключение

Успешная реализация RPL может позволить решению IoT достичь заявленных целевых функций и целей. В рамках RPL типичной целью является построение DODAG на основе определенного OF и поддержание соединений с набором хостов. RPL специально оптимизирован для моделей трафика MP2P и P2MP. Узлы не имеют статусов, и в каждом узле хранится минимальная информация о состоянии маршрутизации. RPL также учитывает атрибуты соединения и узла при выборе путей. Кроме того, отказы каналов не вызывают глобальной переоптимизации сети.

При масштабном развертывании IoT (с участием тысяч узлов и распределением по большой географической территории), когда при разработке и реализации маршрутизации учитываются различные функции, возможности и свойства, доступные в RPL, время автономной работы IoT-решения составляет года.

Возможность использования сетей на базе IP может значительно снизить энергопотребление и затраты, связанные с беспроводной связью IoT, которая в противном случае потребовала бы дорогостоящих мобильных вышек и связи на базе GSM/EDGE. Такая реализация RPL может существенно изменить развертывание решений IoT в таких приложениях, как городские сенсорные сети.

Топологии RPL включают DAG и DODAG с несколькими корнями и без петель, или DAG с корнями в одной цели (без выходных ребер).

Система управления промышленным маршрутизатором включает в себя блок схемы, блок силовой схемы, блок управления ARM, сетевой блок, блок коммутатора и высокоскоростной блок RS485. Система отличается тем, что в блоке силового модуля используется специальный источник питания U1 от ST: PM6641. PM6641 может генерировать три источника питания: 3,3 В, 1,8 В и 1,2 В соответственно. Блок управления ARM использует STSPEAr320S и разделен на два канала, один RGMII используется для подключения к PHY, другой RGMII подключен к RTL Switch; один USB используется для подключения 3G модуля, кроме того, USB используется для преобразования UART; сетевой блок выбирает PHY U17:KSZ8081, а высокоскоростной RS485 блок включает трансивер, и скорость передачи данных трансивера превышает 1Mpbs.