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

Полный текст

Введение

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

Большинство функциональных требований могут быть удовлетворены при использовании протоколов прикладного и сетевого уровня модели 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, а обоснование принятых решений представлено в следующем разделе.

 

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

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

 

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

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

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

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

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

Сравнительная таблица физического уровня 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) по следующим функциям и параметрам:

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

 

Таблица 2. Канальный уровень: 802.15.4 и LoRa

Функция или параметр	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, счетчик кадров

 

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

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

 

Рис. 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. Данный протокол включает в себя следующие функции:

В системе 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 более эффективна в ухудшенных условиях (потеря пакетов);

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

4. Транспортный уровень

На транспортном уровне, как упоминалось ранее, предлагается использовать привычные протоколы 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 требует, чтобы устройства имели необходимые ресурсы, такие как аппаратный механизм шифрования и другие.

5. Прикладной уровень

На прикладном уровне, теоретически, могут использоваться любые протоколы стека 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.

 

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

Fig. 4. Appearance of the test bench

 

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

 

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

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

 

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

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

 

Рис. 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, интернет транспортных средств и т. п.).

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

Об авторах

Никита Дмитриевич Кустов

Сибирский государственный университет науки и технологий имени академика М. Ф. Решетнева

Автор, ответственный за переписку.
Email: kustovnd@sibsau.ru

ассистент, кафедра безопасности информационных технологий

Россия, 660037, Красноярск, проспект имени газеты «Красноярский Рабочий», 31

Клим Сергеевич Евдокимов

Сибирский государственный университет науки и технологий имени академика М. Ф. Решетнева

Email: sanecsan@mail.ru

инженер, научно-производственная лаборатория «Малые космические аппараты»

Россия, 660037, Красноярск, проспект имени газеты «Красноярский Рабочий», 31

Александр Владимирович Шахматов

Сибирский государственный университет науки и технологий имени академика М. Ф. Решетнева

Email: sanecsan@mail.ru

инженер, кафедра безопасности информационных технологий

Россия, 660037, Красноярск, проспект имени газеты «Красноярский Рабочий», 31

Список литературы

Дополнительные файлы