Интегрированная космическая сеть: обоснование архитектурных и технических решений космической миссии Reshucube-2

В настоящее время наблюдается активный период развития сферы малых космических аппаратов (МКА). На текущий момент, к примеру, в рамках проекта «Space-π» было запущено 29 МКА типа CubeSat. В том числе, аппарат ReshUCube-1 СибГУ им. М. Ф. Решетнева [1]. Всего по проекту «Space-π» в течение нескольких лет планируется запустить, в общей сложности, 100 таких МКА. Таким образом, актуальным направлением развития этой отрасли представляется организация межспутникового взаимодействия и интеграция космического сегмента с наземными сетями [2]. В связи с этим, приоритетной задачей для грядущей космической миссии ReshUCube-2 является тестирование архитектуры интегрированной космической сети. Очевидно, что речь идет об относительно низкоскоростной передаче (порядка 210–218 бит/c) в связи с дальностью передачи.

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

Предлагаемая сетевая архитектура

Сетевая архитектура подразумевает наличие как минимум наземного и космического сегмента. Узлы космического сегмента – МКА на низких околоземных орбитах. Наземный сегмент может быть представлен привычными сетями (Ethernet, Wi-Fi, WiMAX, Bluetooth и т. д.), сетями интернета вещей (Internet of Things, IoT) [3] или интернета транспортных средств, как это представлено в работе [4].

При этом предусматривается три основных класса устройств такой сети:

• 1)    конечный узел (Host) – узел (например, датчик, сенсор), передающий и принимающий сообщения, не имеющий функций маршрутизации;

• 2)    маршрутизатор (Router) – узел, выполняющий, в том числе, функции конечного узла и обладающий функциями маршрутизации внутри сети;

• 3)    граничный маршрутизатор (Border Router) – узел, выполняющий, в том числе, функции конечного узла и маршрутизатора, обладающий при этом функциями маршрутизации между сетями различных стандартов.

Общий вид предлагаемой сетевой архитектуры представлен на рис. 1.

Рис. 1. Общий вид сетевой архитектуры интегрированной космической сети

Fig. 1. Network architecture general view of the space integrated network

Описание требований к архитектуре

В работе [5] представлены исходные требования, которые были определены при проектировании архитектуры интегрированной космической сети. Ниже предложен уточненный, на текущий момент, перечень этих требований:

• –    низкая стоимость электронной компонентной базы;

• –    возможность передачи на большое расстояние;

• –    помехоустойчивость и устойчивость к эффекту Доплера;

• –    высокая энергоэффективность;

• –    низкое потребление аппаратных ресурсов;

• –    обеспечение динамической маршрутизации и поддержка ячеистой топологии сети;

• –    поддержка стандартных протоколов верхних уровней стека TCP/IP (Transmission Control Protocol / Internet Protocol);

• –    минимальное, насколько возможно, преобразование на границе разных сегментов сети (наземного и космического);

• –    сжатие сетевых заголовков для увеличения соотношения полезной нагрузки к общему объему кадра;

• –    минимальное, насколько возможно, количество операций фрагментации и сборки пакетов;

• –    автоконфигурация сетевых адресов в отсутствии возможности централизованного управления адресами и поиск соседних узлов;

• –    возможность использования «облегченных» прикладных протоколов;

• –    поддержка функций безопасности.

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

Остальные функции могут быть реализованы программно. Это, в свою очередь, подразумевает выбор соответствующих сетевых протоколов, общесистемного и прикладного программного обеспечения.

Предлагаемый стек сетевых технологий

Использовать стандартный стек TCP/IP в исходном виде не представляется возможным, в связи с чем предлагается использовать сочетание различных протоколов.

Большинство функциональных требований могут быть удовлетворены при использовании протоколов прикладного и сетевого уровня модели OSI (Open Systems Interconnection), разработанных для IoT. Это протоколы 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) [6], RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [7], CoAP (Constrained Application Protocol) [8] и др. Однако данные протоколы были разработаны для группы стандартов персональных сетей IEEE (Institute of Electrical and Electronics Engineers) 802.15.4 [9]. Очевидно, что физические ограничения данного стандарта не удовлетворяют требованиям по дальности связи и помехоустойчивости. В связи с этим, предлагается использовать технологию физического уровня LoRa (Long Range) [10], отказавшись при этом от канального уровня, входящего в технологию LoRaWAN [11] (Long Range Wide-Area Networks). Для того чтобы обеспечить совместимость канального и физического уровней, необходимо ввести дополнительный подуровень, содержащий PHY-MAC драйвер.

Общий вид предлагаемого стека сетевых технологий приведен на рис. 2, а обоснование принятых решений представлено в следующем разделе.

	LoRaWAN netstack		6L0WPAN netstack			ReshUCube netstack
Application layer	Application protocols		CoAP	Application protocols		CoAP	^ppllcatюn protocols
Transport layer	-		TCP	UDP		TCP	UDP
Network layer	-		IPv6			IPv6	RPL
			6L0WPAN			6L0WPAN
Data link layer	LoRa MAC		802.15.4 MAC			802.15.4 MAC PHY-MAC driver
Physical layer	LoRaPHY		802.15.4 PHY			LoRaPHY

Рис. 2. Общий вид предлагаемого стека сетевых технологий

Fig. 2. General view of the proposed network technology stack

Обоснование выбора сетевых технологий

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

1.    Физический уровень

На данном уровне необходимо провести сравнительный анализ основных функций и параметров технологий LoRa и IEEE 802.15.4.

Ключевыми являются следующие функции и параметры:

– обнаружение активного канала. Для 802.15.4 предусмотрена функция ED (Energy Detection), предназначенная для использования сетевым уровнем как часть алгоритма выбора канала. Это оценка мощности принятого сигнала в пределах полосы пропускания канала. Для LoRa подобной технологии не предусмотрено, однако приемник LoRa может переключиться на другой канал по запросу;

– определение качества приема. Для 802.15.4 предусмотрено измерение LQI – это характеристика силы и/или качества принятого кадра. Измерение может быть реализовано с использованием ED приемника, оценки отношения сигнал/шум или комбинации этих методов. Для LoRa нет механизма, объединяющего параметры качества, однако можно получить параметры RSSI (Received Signal Strength Indicator) и SNR (Signal-to-Noise Ratio) по отдельности;

– идентификация активности. 802.15.4 должен обеспечивать возможность выполнения CCA (Clear Channel Assessment) в соответствии, по крайней мере, с одним из следующих методов:

энергия выше порогового значения и/или обнаружение несущей, или CCA постоянно должен сообщать о том, что передатчик находится в состоянии ожидания. Обнаружение активности канала CAD (Channel Activity Detection) LoRA используется для обнаружения присутствия сигнала путем обнаружения преамбулы или символов данных;

– настройка параметров передачи. Для 802.15.4 параметры передачи зависят от используемого метода модуляции. Для LoRa: SF (Spreading Factor) – соотношение между номинальной скоростью передачи данных и скоростью модуляции, BW (Bandwidth) – ширина полосы пропускания (в кГц), CR (Coding Rate) – частота кодирования для защиты от ошибок;

– оптимизация низкой скорости передачи. Для низких скоростей передачи данных в LoRa и длительной передачи полезных нагрузок может быть включена оптимизация низкой скорости передачи данных – LDRO (Low Data Rate Optimization). Для 802.15.4 такой технологии не предусмотрено;

– скорость передачи. Для 802.15.4 может составлять до 250 кбит/с, для LoRa – от 300 бит/с до 27 кбит/с;

– максимальное расстояние передачи. Для 802.15.4 ограничено 100 м, для LoRa может достигать 500 км и более.

Сравнительная таблица физического уровня LoRa и 802.15.4 представлена ниже (табл. 1).

Таблица 1

Физический уровень: 802.15.4 и LoRa

Функция или параметр	802.15.4 PHY	LoRa PHY
Обнаружение активного канала	ED	–
Определение качества приема	LQI на основе ED и/или SNR	RSSI или SNR
Идентификация активности	CCA	CAD
Настройка параметров передачи	Зависит от модуляции	SF, BW, CR
Оптимизация низкой скорости передачи	–	LDRO
Скорость передачи	до 250 кбит/с	300 бит/c – 27 кбит/c
Максимальное расстояние передачи	до 100 м	свыше 500 км

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

Качество приема в LoRa определяется теми же параметрами, что и в 802.15.4, но они не объединены в общий механизм (как LQI в 802.15.4). Оценка качества хотя бы по одному из параметров (RSSI, что предпочтительнее, или SNR) является достаточной (описание LQI в стандарте 802.15.4 это допускает).

Идентификация активности в LoRa с помощью CAD также соответствует требованиям (в стандарте 802.15.4 один из вариантов работы механизма CCA аналогичен).

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

2.    Канальный уровень

Для данного уровня необходимо провести аналогичное сравнение (канальные функции LoRa определены в стандарте LoRaWAN) по следующим функциям и параметрам:

– механизм «суперкадра». В 802.15.4 суперкадр ограничен маяками, может иметь активную (период, в течение которого устройства могут случайным образом получать доступ к среде, и период гарантированного доступа) и неактивную (период, в который координатор может перейти в режим низкого энергопотребления) части. Такая структура используется опционально. Для LoRa такой механизм не предусмотрен;

– проверка целостности кадров. В 802.15.4 циклическая проверка избыточности (CRC) используется для обнаружения ошибок в каждом кадре, а также к каждому фрагменту прилагается последовательность проверки целостности фрагмента. Для LoRa такая функция может опционально использоваться как на канальном, так и на физическом уровне;

– подтверждение доставки кадров. Успешный прием и проверка кадра опционально сопровождается подтверждением. Это применимо к обеим технологиям;

– доступ к среде. Методы доступа, определенные в стандарте 802.15.4, следующие: Unslot-ted/Slotted CSMA-CA (Carrier Sense Multiple Access With Collision Avoidance), TSCH (Time Slotted Channel Hopping) CCA, TSCH CSMA-CA, CSMA-CA с PCA (Priority Channel Access), LECIM (Low-Energy Critical Infrastructure Monitoring) ALOHA с PCA. Методы доступа, определенные в стандарте LoRa: Pure/Slotted ALOHA;

– размер кадра. Для 802.15.4 – 127 байт, для LoRa 59-230 байт;

– поддерживаемые топологии. Для 802.15.4 – звездообразная или одноранговая, для LoRa – звездообразная или «звезда из звезд»;

– функции безопасности. В обоих стандартах приведен аналогичный алгоритм шифрования AES (Advanced Encryption Standard) на канальном уровне, который может использоваться опционально. Однако, в дополнение, для LoRa предусмотрен механизм от атак воспроизведения.

Сравнительная таблица канального уровня LoRa и 802.15.4 представлена в табл. 2.

Стандарт канального уровня LoRaWAN по большей части соответствует 802.15.4. По некоторым параметрам LoRa выигрывает (например, в части гибкости CRC, защите от атак воспроизведения). В части механизма управления доступом – проигрывает за счет отсутствия вариативности. Однако наибольшей проблемой является отсутствие поддержки у LoRaWAN одноранговой (ячеистой) топологии [12]. Кроме того, возникает вопрос адаптации вышележащих уровней.

Таким образом, наиболее правильным решением представляется использование 802.15.4 в качестве протокола канального уровня. Основной задачей, в этом случае, является адаптация функций канального уровня к сервисам, предоставляемым физическим уровнем (в данном случае – LoRa PHY). Функции драйвера, которые следует реализовать, приведены на рис. 3.

PHY-MAC driver

Frame mapping

Channel mapping

CCA mapping

SF configuration

BW configuration

CR configuration

LDRO configuration

| | LQI mapping^

LoRa PHY

| LoRa frame^

\.°R?™Y I LoRa CAD channels ] I _______

BW

OR

LDRO | | RSSI/SNR "|

Канальный уровень: 802.15.4 и LoRa

Таблица 2

Функция или параметр	802.15.4 MAC	LoRa MAC
Механизм «суперкадра»	+	–
Проверка целостности кадров	На канальном уровне	На физическом и канальном уровнях
Подтверждение доставки кадров	+	+
Доступ к среде	Unslotted/Slotted CSMA-CA, TSCH CCA, TSCH CSMA-CA, CSMA-CA с PCA, LECIM ALOHA с PCA	Pure/Slotted ALOHA
Размер кадра	127 байт	59–230 байт
Поддерживаемые топологии	Звездообразная или одноранговая	Звездообразная     или «звезда из звезд»
Функции безопасности	AES	AES, счетчик кадров

| Framing |

LQI

CSMA/CA

802.15.4 MAC

Рис. 3. Функции PHY-MAC драйвера

Fig. 3. Functions of the PHY-MAC driver

3.    Сетевой уровень

Базовым сетевым протоколом в описываемом стеке для поддержки TCP/IP сетей предлагается применять протокол IPv6. Минимальная единица передачи для IPv6 составляет 1280 октетов, однако максимальный размер MAC-кадра, определенный IEEE 802.15.4, составляет 127 байт, где 25 байт зарезервированы для накладных расходов на кадр и оставлено только 102 байта для полезной нагрузки. Ситуация ухудшается, если канальный уровень накладывает дополнительные накладные расходы в целях безопасности, добавляя вспомогательный заголовок безопасности в MAC-кадр, который в максимальном случае оставляет только 81 байт для пакета IPv6. Таким образом, полный пакет IPv6 не помещается в кадр 802.15.4.

Кроме того, поскольку заголовок IPv6 в пакете IPv6 составляет 40 байт, для верхних уровней остается только 41 байт. Резервируя либо 8-байтовый заголовок протокола UDP (User Datagram Protocol), либо 20-байтовый заголовок протокола TCP, добавленный на транспортном уровне, пакет IPv6 непрактично оставляет только несколько байт пространства для прикладных данных.

Таким образом, предлагается применять в качестве уровня адаптации между канальным и сетевым уровнями протокол 6LoWPAN. Данный протокол включает в себя следующие функции:

• –    сжатие заголовка. В настоящее время IETF (Internet Engineering Task Force) в документе RFC6282 [13] рекомендует использовать IPHC для сжатия заголовка IPv6. IPHC обеспечивает эффективное сжатие IPv6-адресов – локальных, многоадресных и глобальных. В лучшем случае (при обмене между устройствами в одной сети) заголовок может быть сжат до 2 байт. В худшем случае (при глобальной маршрутизации) IPHC обеспечивает около 50 % сжатия;

• –    фрагментация и повторная сборка. Уровень адаптации должен фрагментировать пакеты IPv6 перед их отправкой и повторной сборкой при приеме. Каждому фрагменту предшествует 4- или 5-байтовый заголовок фрагментации;

• –    маршрутизация [14]. Маршрутизация – функция передачи пакета данных с одного устройства на другое, иногда с помощью ретрансляций через несколько промежуточных узлов. В зависимости от уровня, на котором расположен механизм маршрутизации, определены две ее категории: mesh-under или route-over.

В системе mesh-under маршрутизация данных происходит прозрачно, следовательно, mesh-under-сети можно считать одной IP-подсетью. В такой системе есть только один IP-маршрутизатор – граничный, установлен один широковещательный домен, чтобы гарантировать совместимость с протокола IPv6 более высокого уровня, такого как обнаружение дублирования адреса.

В route-over-сетях маршрутизация имеет место на сетевом уровне. Наиболее широко используемым протоколом маршрутизации в route-over-сетях 6LoWPAN на сегодня является RPL, как определено IETF в RFC6550 [7]. RPL поддерживает два различных режима маршрутизации: режим c сохранением и режим без сохранения. В режиме с сохранением все устройства в 6LoWPAN-сети конфигурируются как маршрутизаторы, которые поддерживают таблицу маршрутизации и хранят таблицу соседних узлов. В режиме без сохранения есть единственное устройство с таблицей маршрутизации – граничный маршрутизатор. Следовательно, используется маршрутизация от источника.

При route-over пакет IPv6 восстанавливается на каждом промежуточном устройстве, чтобы принять решение о маршрутизации. И наоборот, в mesh-under решение о маршрутизации принимается на уровне 6LoWPAN и, следовательно, только с фрагментами пакета IPv6. В этом случае пакет IPv6 восстанавливается только на оборудовании назначения. Следовательно, mesh-under позволяет сократить задержку передачи, route-over более эффективна в ухудшенных условиях (потеря пакетов);

• –    автоконфигурация IP-адреса и обнаружение соседнего узла. Автономная генерация IPv6-адреса устройства. Для IPv6 он позволяет устройству автоматически генерировать свой IPv6-адрес без какого-либо взаимодействия с внешним сервером DHCP или аналогичным устройством. Чтобы получить адрес, хост может связываться через протокол NDP (Neighbor Discovery Protocol) [15]. Впрочем, многие из функций NDP также включены в RPL;

  – функции безопасности [16]. Использование IPsec (IP Security) возможно, но шифрование потребляет много ресурсов и метод обмена ключами IKEv2 использовать нельзя. Необходимым условием является управление ключом шифрования с использованием минимальной полезной нагрузки, а также ограничение сообщений, которыми обмениваются узлы. Для сетей 6LoWPAN было реализовано расширение протокола SEND (SEcure Neighbor Discovery protocol), RFC3971 [17], для защиты механизма обнаружения соседей, которое называется LSEND (Lightweight Secure Neighbor Discovery Protocol).

При применении протокола 6LoWPAN достигается:

• –    поддержка стандартных протоколов стека TCP/IP;

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

• –    минимальное преобразование на границе сегментов (за счет установки на границе специальных пограничных маршрутизаторов);

• –    сжатие сетевых заголовков (за счет механизмов IPHC и, опционально, NHC (Next Header Compression);

• –    минимальное количество операций фрагментации и сборки (за счет того же сжатия);

• –    автоконфигурация сетевых адресов и поиск соседних узлов (за счет механизма ND и протокола RPL).

4.    Транспортный уровень 5.    Прикладной уровень

На транспортном уровне, как упоминалось ранее, предлагается использовать привычные протоколы TCP и UDP. Также, как было замечено, для UDP можно использовать механизм NHC для дополнительного сжатия UDP заголовка от 8 до 4 байт.

На транспортном уровне в 6LoWPAN-сетях, рекомендуется использовать механизм TLS (Transport Layer Security). TLS, как определено в RFC8446 [18], работает поверх TCP. В условиях ограниченных ресурсов, где UDP выбран в качестве протокола транспортного уровня, для обеспечения безопасности на транспортном уровне может использоваться DTLS (Datagram Transport Layer Security), RFC6347 [19]. Однако нужно отметить, что реализация TLS/DTLS требует, чтобы устройства имели необходимые ресурсы, такие как аппаратный механизм шифрования и другие.

На прикладном уровне, теоретически, могут использоваться любые протоколы стека TCP/IP. Разумеется, предпочтительно использовать протоколы, обеспечивающие минимальный уровень загрузки сети.

Помимо этого, предлагается использовать специальные «облегченные» протоколы для IoT. К примеру, протокол CoAP. CoAP – это протокол со следующими основными характеристиками: клиент-серверная архитектура; REST-архитектура (Representational State Transfer); нижележащий протокол – UDP; асинхронная транзакционная модель; поддержка URI (Uniform Resource Identifier) и MIME (Multipurpose Internet Mail Extensions); простой и небольшой заголовок (менее 10 байт); настройка системы прокси и «кеширования»; для безопасности используется DTLS.

Практическая реализация

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

С точки зрения программной реализации также могут быть рассмотрены различные варианты. К примеру, операционные системы для IoT Contiki-NG и RIOT. В данном случае было отдано предпочтение последней в связи с высоким уровнем поддержки этой операционной системы. Так или иначе, обе системы поддерживают стек TCP/IP, 6LoWPAN и стандарт 802.15.4, однако их совместное использование с технологией LoRa требует дополнительных разработок в части драйвера адаптации, о котором упоминалось ранее.

На сегодняшний день был создан тестовый стенд, на основе которого планируется отладка сетевого взаимодействия между узлами. Для тестового стенда были разработаны 5 унифицированных плат на основе упомянутого микроконтроллера STM32WLE5CC. Данные платы оснащены LoRa-приемопередатчиками с мощностью 25 мВт, работающими на нелицинзируемой частоте 868 МГц. Внешний вид развернутого тестового стенда и пример тестовой архитектуры приведен на рис. 4. Здесь три узла могут выполнять функции маршрутизатора или конечного узла: один узел – граничный маршрутизатор, один узел – сетевой сниффер, позволяющий перехватывать пакеты, передаваемые между платами. К граничному маршрутизатору подключен IPv6 узел. К этому же узлу подключен сниффер, чтобы обеспечить интерфейс.

Рис. 4. Внешний вид тестового стенда

Fig. 4. Appearance of the test bench

На рис. 5 приведен пример инициализации устройств. Для каждого из четырех активных узлов выводится список соседних узлов (ND) и таблица маршрутизации (RPL). Граничный маршрутизатор (подключенный как /dev/ttyUSB0) выполняет функции корневого. Можно увидеть, что узлы, по-умолчанию, образуют топологию DODAG (Destination Oriented Directed Acyclic Graph). Дочерние узлы находятся в непосредственной близости к корневому маршрутизатору и, таким образом, автоматически относятся к первому уровню графа, что отмечено символом «Х» в графе «parent table». Это говорит о том, что предложенное решение является вполне жизнеспособным: операционная система и, в том числе, сетевой стек функционируют в необходимом объеме.

Кроме того, был разработан прототип полезной нагрузки МКА ReshUCube-2. По аналогии, данная плата оснащена микроконтроллером STM32WLE5CC. Ключевым отличием является расчётная мощность – около 2 Вт и рабочая частота в лицензируемом частотном диапазоне – 435 МГц. Здесь проводится тестирование иных аспектов: аппаратных функций, работоспособности, надежности и т. д. Внешний вид платы прототипа полезной нагрузки приведен на рис. 6. На основе данного прототипа сейчас изготавливается радиомодуль, предназначенный непосредственно для установки на МКА.

Рис. 5. Результат инициализации тестового стенда

Fig. 5. The result of initialization of the test bench

Рис. 6. Внешний вид тестовой платы полезной нагрузки

Fig. 6. Appearance of the payload test board

Заключение

В результате работы было приведено обоснование архитектурных и технических решений в соответствии с функциональными и техническими требованиями, выявленными в процессе проектирования МКА ReshUCube-2. Определен стек сетевых протоколов и технологий с учетом различных параметров настройки (режимов сжатия, маршрутизации и др.). Ключевые протоколы стека: LoRa, 802.15.4, IPv6, 6LoWPAN, RPL, TCP, UDP и CoAP. Создана аппаратная платформа, в основе которой микроконтроллер STM32WLE5CC. Выбрано и протестировано программное обеспечение: операционная система RIOT и PHY-MAC драйвер. Эти решения также могут быть полезны в перспективе развития проекта интегрированной космической сети и при разработке последующих космических миссий. Определенные в работе программные и аппаратные технологии могут быть использованы для воспроизведения полученных результатов. Кроме того, предложенный стек сетевых технологий может быть применен в иных отраслях (например, IoT, интернет транспортных средств и т. п.).

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