IoT-сети проектировали для миллионов устройств, но они захлебываются уже от тысяч. Когда в нашем районе на секунду моргнул свет, 10 000 умных счетчиков одновременно потеряли связь и начали переподключаться. Три четверти так и не смогли выйти в эфир. Проблема в RACH — канале случайного доступа. При массовых подключениях он превращается в узкое горлышко, куда каждый пытается прорваться первым.

Меня зовут Максим Князев, старший системный инженер К2 Кибербезопасность, и я натренировал пять ИИ-агентов для управления этим хаосом. Один прогнозирует пики нагрузки, другой распределяет временные слоты, третий управляет мощностью передачи, четвертый распределяет устройства по типам и пятый оптимизирует расход батарей. В итоге количество коллизий упало с 26% до 7%, энергопотребление на 35%, а успешность подключений выросла до 96% по сравнению с использованием статического метода без агентов. Под катом рассказываю, как это работает.

Главный виновник всех бед — RACH, Random Access Channel. По-русски — канал случайного доступа. Работает он просто: когда у IoT-устройства появляются данные, оно не ждет разрешения базовой станции. Оно просто выбирает свободный временной слот и пытается передать сигнал. Это просто и эффективно, но только до тех пор, пока все устройства не попытаются выйти на связь одновременно.

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

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

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

От грубой силы к проблескам интеллекта

Первое решение, которое приходит в голову — Access Class Barring. Система просто запрещает части устройств выходить на связь, чтобы разгрузить канал. Решение рабочее, но это как лечить головную боль гильотиной — грубо и с побочными эффектами. ACB не различает важность сигналов. Датчик утечки газа и погодная станция для него равны — оба могут оказаться за бортом с одинаковой вероятностью.

Я решил подойти к проблеме иначе. Взял обучение с подкреплением — тот самый Reinforcement Learning, на котором тренируют ботов играть в шахматы. Только я учил агента управлять потоком IoT-устройств через Access Class Barring и распределения RACH-слотов. Снизил коллизии на 10% — получи +10 очков, увеличил задержку на 20 мс — получи −5. Так агент учится максимизировать награду в долгосрочной перспективе. 

По сравнению со статической конфигурацией, одиночный RL-агент сократил количество коллизий на 74%, поднял успешность подключений на 16% и улучшил энергоэффективность устройств на 15%. Казалось бы, задача решена, но когда я усложнил сценарии тестирования, приблизил к реальности, начались проблемы.

Агент отлично решал одну задачу — минимизацию коллизий, но реальность оказалась сложнее грубой модели.

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

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

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

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

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

«Пять друзей Оушена»: мультиагентная система

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

Чтобы они работали как единый организм, я создал интеграционный слой поверх симулятора NS-3. Он собирает полную картину состояния сети и отправляет каждому агенту только релевантную информацию. Интеграционный слой отвечает за то, чтобы решения не конфликтовали друг с другом.

Агент 1: Диспетчер RACH-слотов

Первый агент работает в реальном времени по двум метрикам: количество коллизий и процент успешных подключений. Много коллизий — увеличивает число RACH-слотов, чтобы разгрузить канал. Канал простаивает — сокращает слоты, экономя ресурсы. Чистая тактика без стратегии: он реагирует на ситуацию, не пытаясь ее прогнозировать.

Агент 2: Предсказатель пиковых нагрузок

В отличие от Диспетчера, Предсказатель работает на опережение. Анализирует временные ряды и выявляет паттерны: утренняя активация офисных датчиков в 9:00, ночной сбор данных со счетчиков в 3:00, пики по дням недели. За несколько минут до прогнозируемого всплеска отправляет сигнал другим агентам подготовить дополнительные ресурсы. Классическое предиктивное управление на основе исторических данных.

Агент 3: Классификатор трафика

Он распределяет устройства по трем категориям: периодические (метеостанции с регулярной передачей), критические (датчики утечки газа — редко, но срочно) и фоновые (сбор телеметрии). Для каждой категории настраивает свои параметры ACB и выделяет ресурсы. При появлении критического сигнала временно блокирует фоновый трафик. Обеспечивает QoS без перегрузки канала.

Агент 4: Балансировщик нагрузки

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

Агент 5: Менеджер энергопотребления

Оптимизирует расход батарей. Анализирует количество повторных попыток подключения, уровни сигнала и текущие режимы энергосбережения (PSM, eDRX). Когда устройство тратит слишком много энергии на неудачные попытки, корректирует параметры: либо ограничивает число повторов, либо увеличивает периоды сна между попытками. Его цель — добиться максимального времени автономной работы при сохранении связности.

Песочница для ИИ: строим цифровой город для тестов

Агентам нужна была реалистичная среда для обучения — цифровой двойник сотовой сети, где они отрабатывали бы «навыки» без риска для реальной инфраструктуры.

Для этого я использовал Network Simulator 3 версии 3.35 с полной поддержкой NB-IoT по спецификации 3GPP Release 13. Представьте игровой движок вроде Unreal Engine, который вместо графики с маниакальной точностью воссоздает физику распространения радиоволн, логику сетевых протоколов и поведение тысяч устройств — это и есть NS-3.

Агенты работали с детальной эмуляцией физического канала NPRACH со всеми процедурами генерации преамбул и установления соединений. NS-3 позволял управлять теми же параметрами, что доступны реальному оператору: количество RACH-слотов, коэффициент ACB, максимальное число повторов передачи.

Симулятор написан на C++, а RL-агенты — на Python. Для связи между ними я использовал фреймворк ns3-gym, который представляет симулятор как среду OpenAI Gym.

Работает это так: симулятор передает состояние сети (коллизии, загрузка, задержки) через фреймворк ns3-gym в Python. Агенты обрабатывают данные и возвращают решения — например, изменить число RACH-слотов или увеличить паузы между попытками. ns3-gym транслирует команды обратно в C++, симулятор применяет новые параметры и продолжает работу. Цикл «наблюдение — решение — действие» повторяется на каждом шаге симуляции, позволяя агентам учиться в реальном времени.

Каждому агенту подобрал алгоритм обучения под его задачу.

Для Диспетчера (агент 1), Классификатора (агент 3) и Балансировщика (агент 4) выбрал DQN (Deep Q-Network). Этот алгоритм хорошо подходит для задач с дискретным пространством действий: выбор количества RACH-слотов (4, 6, 8 или 10), установка коэффициента ACB (0.5, 0.7, 0.9) и так далее.

Менеджер энергопотребления работает с непрерывным пространством действий (мощность передачи от 0 до 100%, длительность периодов сна от 0.1 до 10 секунд), и должен плавно их регулировать. Оптимальный выбор для него — DDPG.

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

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

Результаты обучения

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

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

Второй сценарий — условно деревенский. Это территория с радиусом в 10–15 километров, где находится всего 50 устройств. Здесь нет большой нагрузки, но большие расстояния означают слабый сигнал. Задача агентов — добиться энергоэффективной передачи данных, ведь каждая повторная передача сокращает срок службы батареек в датчиках. 

Сравнивал три подхода: 

1. Статическая конфигурация (базовый метод).

2. Одноагентная RL-система (наша предыдущая разработка).

3. Мультиагентная система (пять специализированных агентов).

Давайте разберем эти результаты.

Тестирование в «городе»

Команда из пяти агентов справилась с задачей управления спектром в условиях максимальной нагрузки. Посмотрим на конкретные показатели.

• Коллизии снизились в четыре раза. Статическая система допускала столкновения в 26% случаев — каждое четвертое устройство конфликтовало с соседом при попытке передачи. Одиночный агент снизил этот показатель до 15%. Команда агентов довела его до 7%. Теперь вероятность коллизии при выходе в эфир уменьшилась почти в четыре раза по сравнению со статическим распределением.

• Успешные подключения выросли до 96%. Практически все устройства выходили на связь с минимальным числом попыток. В условиях массового подключения такой уровень надежности раньше был недостижим.

• Задержка сократилась с 5 до 1,5 секунды. Получился почти мгновенный отклик. В критических приложениях такая разница может быть очень важна.

• Энергопотребление упало на 35%. Всего 3,6 мДж на успешную передачу против 5,5 мДж при статическом управлении. Для устройств на батарейках это означает месяцы дополнительной работы без подзарядки.

Тестирование в «деревне»

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

• Коллизии снизились до 1%. Практически полное отсутствие конфликтов при передаче данных. Для сравнения: статическая система давала 8% коллизий даже при малой плотности устройств.

• Успешность подключений достигла 98%. Почти все устройства устанавливали связь с первой попытки.

• Энергопотребление — главное достижение. Всего 1,4 мДж на передачу против 2,1 мДж у статической системы. Снижение на 33% достигнуто за счет работы Менеджера энергопотребления (агент 5), который настраивал режимы сна и минимизировал число повторных передач для устройств со слабым сигналом.

Почему мультиагентный подход работает

Такие высокие показатели обеспечиваются благодаря разделению функций между специализированными агентами. В городском сценарии Предсказатель (агент 2) предсказывал всплески трафика, а Диспетчер (агент 1) заранее перераспределял ресурсы под растущую нагрузку. Параллельно Классификатор трафика (агент 3) резервировал каналы для критически важных сообщений, предотвращая их блокировку обычным трафиком.

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

Эксперименты подтвердили: распределение функций между специализированными RL-агентами дает измеримый прирост производительности. Метод показал снижение коллизий в 3-4 раза, сокращение задержек в 3 раза и экономию энергии на 30-35% по сравнению со статическим управлением спектром в сетях NB-IoT.

Дальнейшие шаги

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

Мультиагентный подход с использованием обучения с подкреплением показал свою эффективность в симуляции. Теперь предстоит проверить и адаптировать технологию для реальных условий эксплуатации. В симуляторе NS-3 агенты работали в контролируемых условиях. На реальных базовых станциях появятся радиопомехи, аппаратные сбои, непредсказуемое поведение устройств. Это покажет, насколько алгоритмы устойчивы к реальным условиям эксплуатации.

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

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

Еще многое предстоит сделать, но теперь понятно, в каком направлении двигаться. Полученные результаты — это реальный путь повышения эффективности работы интернета вещей.